Information security management — public summary

This page summarises the information security management system (ISMS) operated by Inger s.r.o. It is mapped to the control domains of ISO/IEC 27001:2022 Annex A but is not itself a certification. The goal is transparency: every domain below has a named responsible party, an implementation, an evidence source, and a review cadence. What is public is published. What is engagement-specific is available under NDA.

1. Information security policy

Commitment

We build software for operations that cannot afford to fail, and we hold ourselves to the controls we recommend to clients.

Scope

All information systems operated by Inger s.r.o. and all client data processed under contract.

Public artifact

Trust & security page (overview) · Vendor DD (detailed posture).

Internal artifact

ISMS policy document (1-page statement + control register). Available under NDA.

Review

Annual. Last review: 2026-04-23.

2. Organization of information security

Governance model

Inger is a micro entity. Information security governance rests with the founder. Where engagement size warrants it, a named security contact is assigned per engagement.

Roles

Security owner: Julius German. Data protection single point of contact: info@inger.sk. Security disclosure: security@inger.sk.

Segregation of duties

Limited by entity size. Compensating controls: mandatory 2FA on code-control systems, paired review for production changes on client engagements, audit log retention.

External contacts

Slovak NBÚ (cybersecurity authority), ÚOOÚ (data protection supervisory authority), hosting provider support (Speedweb s.r.o.), GitHub security team. Contact paths documented in the incident response runbook (NDA).

3. Human resources security

Hiring

Inger is a single-operator engineering studio. New engagement-specific collaborators (when needed) sign an NDA and scoped access agreement before data access.

Training

Continuing professional development: hands-on work on ZulienScore and NISMap keeps security knowledge current. Annual focus areas are recorded. No formal training certificates currently collected.

Termination / off-boarding

Credential revocation within 24 h of engagement termination. Client data returned or destroyed within 30 days unless statutory retention applies. Destruction certificate on request.

4. Asset management

Asset inventory

Internal register: operator endpoint, hosting account, GitHub organisation, domain registrations, email infrastructure, client engagement deliverables. Reviewed annually.

Classification

Three classes: Public (site content, marketing), Internal (policies, financials), Client (any data received under DPA). Client class is never committed to public repositories.

Acceptable use

Operator endpoint is dual-purpose but personal use is minimised; no client data leaves the endpoint other than through explicit, logged channels.

Disposal

Hardware decommissioning: full-disk secure erase prior to resale or disposal. No physical media is transferred off-site without encryption.

5. Access control

Identity management

Password manager with strong, unique credentials per service. 2FA mandatory on: GitHub, hosting control panel, email, all cloud services that offer it.

Privileged access

SSH key-only to production (no password). Keys rotated on operator device change or suspected compromise. Deploy keys scoped per repository.

Least privilege

Client engagement access is granted per-engagement, time-bounded, and revoked on completion.

Review

Access review at engagement start, end, and annually for persistent accounts.

6. Cryptography

Data in transit

HTTPS with HSTS max-age=31536000; includeSubDomains; preload on all owned domains. TLS 1.2 minimum, 1.3 preferred (hosting-level default).

Data at rest (operator)

FileVault full-disk encryption on macOS. Firmware password. Automatic screen lock.

Data at rest (hosting)

Hosted at Speedweb s.r.o. in Slovakia. Encryption at rest on the hosting side is not documented to us, so it is not claimed here. The web root is rebuilt from git on every deploy.

Key management

SSH keys stored in OS keychain with passphrase. GPG keys for code signing on roadmap (B-01 P1).

7. Physical & environmental security

Office

Home-office primary. Door lock, restricted access. No client data printed to paper.

Endpoint custody

Operator endpoint never left unattended in unsecured locations. Travel: device stays with operator or locked in hotel safe; full-disk encryption assumed as primary control.

Hosting physical security

Delegated to the hosting provider, Speedweb s.r.o. (Slovakia). No certification is claimed for it.

8. Operations security

Change management

Git-based. Every production change is a commit with traceable authorship. Rollback is a single git revert + redeploy (< 5 min for static site).

Capacity management

Static site with > 20× headroom on baseline traffic. Client service capacity stated per SLA.

Backup

Source code — distributed via git (every clone is a backup). Server content — daily snapshot by hosting provider, 30-day retention. Restore tested on engagement-specific basis.

Logging & monitoring

Server access logs retained for operational incident review. Application error alerts via email. Client engagements include per-SLA monitoring.

Vulnerability management

Hosting-layer patching delegated to the hosting provider (Speedweb s.r.o.). Application-layer: this site ships no runtime dependencies at all — no framework, no bundler, no third-party JavaScript, and no package.json in the repository — so there is no dependency surface to scan rather than a scan we perform. Own-tool scan via ZulienScore, run periodically and published with its date; a11y scan via axe-core on every successful deploy. Client engagements that do carry dependencies are scanned per engagement.

Malware controls

Operator endpoint: macOS Gatekeeper + XProtect + firewall. No untrusted binaries executed.

9. Communications security

Network controls

Operator endpoint uses encrypted-DNS-over-HTTPS. Outbound filtering via Little Snitch. Public Wi-Fi use always paired with VPN or cellular tethering for client work.

Email

SPF is published with a hard fail: v=spf1 a mx include:_spf.speedweb.sk -all. Submission is TLS-only. No forwarding of client data to personal mailboxes. DKIM was published on 2026-09-18 for selector default, closing a gap this page carried openly for months: until then our server signed outbound mail with a key that had never been put in DNS, so receivers returned dkim=permerror (no key for signature) — a signature present and unverifiable. A message sent through this site's own contact form after the change evaluates at Gmail as dkim=pass header.i=@inger.sk and dmarc=pass; the identical path returned dmarc=fail the day before. DMARC reads v=DMARC1; p=none; sp=none; rua=mailto:dmarc@inger.sk and deliberately still monitors rather than enforces — we tighten it once the aggregate reports confirm every legitimate sender is aligned, not before. One thing we would rather state than have you find: on the relay hop our host's forwarder adds a second DKIM signature of its own, and that one does not verify. One valid signature is all DMARC requires, so nothing is being rejected, but a permanently broken signature is untidy and we have raised it with them. All three records are visible to you: dig TXT inger.sk, dig TXT default._domainkey.inger.sk and dig TXT _dmarc.inger.sk.

File transfer

No plaintext transfer of client data. Secure channels only: SSH/SFTP, end-to-end encrypted client platforms, or HTTPS-upload to client-controlled systems.

10. System acquisition, development & maintenance

Secure SDLC

Requirement → threat model (lightweight) → implementation → peer or self-review → test → deploy. Security checks enforced by CI where applicable.

Third-party code

Dependencies selected for maintenance track-record, scoped narrowly, version-pinned. Licence review before inclusion.

Test data

No production personal data used in test environments. Synthetic or anonymised data only.

Separation of environments

Dev / staging / production separation enforced per engagement. Credentials and secrets scoped per environment.

11. Supplier relationships

Subprocessor inventory

Public list for www.inger.sk: /trust §8. Machine-readable: /vendor-dd.json.

Supplier due diligence

Selection criteria: EU/EEA data residency where possible, recognised certification (ISO 27001, SOC 2), contractual SCCs for any non-EEA transfer, documented incident disclosure policy.

Supplier change control

30-day public notice on new subprocessor. Right to object for contracted clients. Termination without penalty if objection unresolved.

12. Information security incident management

Reporting channels

External: security@inger.sk · /.well-known/security.txt · trust.html#disclosure. Internal: runbook in private repository.

Classification

S1 service-down · S2 degraded · S3 contained · S4 informational.

Response SLA (client engagements)

24 h early warning · 72 h initial assessment · 30 d final report. NIS2 Art. 23 aligned.

Post-incident review

Mandatory for S1 and S2. Written within 10 business days of containment. Feeds the risk register.

Regulator notification

Personal data breaches likely to result in risk: ÚOOÚ within 72 h under GDPR Art. 33. NIS2-equivalent notification to affected clients on contract.

13. Business continuity

Static site continuity

Code in distributed git, auto-deployed. RTO < 1 h to alternative host, RPO 0.

Operator continuity

Named stand-in with shared credential manager (break-glass procedure), family notification contact, documented engagement status.

Client engagement continuity

Per-engagement SLA stating RTO / RPO / escalation path. Documented in MSA/SoW.

Testing

Annual tabletop exercise. Real-world tested by rotating operator hardware (2024, 2025).

14. Compliance

Regulatory mapping

Published on /trust §6 and /vendor-dd §5. Covers GDPR, NIS2, DORA, ISO 27001, SOC 2, WCAG 2.2 AA.

Statutory retention

Slovak Act 431/2002 Z.z. for accounting records (10 years). Client engagement data retained per DPA.

Intellectual property

Third-party licences reviewed before inclusion. Work product IP assigned to client on payment per MSA.

Independent review

Annual self-review via own-tooling scan (ZulienScore, NISMap, axe-core). External audit is a P3 roadmap item.

15. How this page is maintained

This summary is re-dated annually in April (latest review is cited in the header) and on any material change. Control descriptions are derived from the internal ISMS policy + control register; where the internal document is more detailed than this summary, the omission is intentional (operational detail, not theatre). Any gap you identify while reviewing this page — or any control you expect to see but do not — is a question we want: info@inger.sk.

Requests for the full internal ISMS document, risk register, incident runbook, or BCP in detail: available under NDA to prospective enterprise clients via the vendor-DD request path — see /vendor-dd §8.