Information Security Policy

Owner: Security Officer · Approved by leadership · Version 1.0 · Effective 27 May 2026 · Next review 27 May 2027

1. Purpose

This policy sets out Glassbreak's commitments to protecting the confidentiality, integrity, and availability of information assets under its control. It is the top-level policy from which all other Glassbreak security policies, procedures, and standards derive their authority.

Glassbreak operates a zero-knowledge break-glass platform. Customers trust us with the means to recover their most critical credentials and to coordinate their emergency response. The integrity of that trust depends on the disciplined operation of the controls described in this policy.

2. Scope

This policy applies to:

All information assets owned, processed, or stored by Glassbreak, including customer data (encrypted ciphertext and metadata), intellectual property, source code, infrastructure-as-code, cryptographic keys, audit logs, and business records.
All workforce members (employees, contractors, advisors, and interns) regardless of location or working arrangement.
All systems Glassbreak operates or procures, including sub-processor services, developer workstations, and any third-party tools that handle Glassbreak information.
All physical and virtual locations where Glassbreak information is accessed or stored.

3. Policy statements

3.1 Confidentiality

Customer secret, contact, and message content is encrypted on the data subject's device with AES-256-GCM before transmission. Glassbreak does not hold the decryption keys and cannot read this content under any circumstance.
Authentication credentials are stored as Argon2id hashes (t=4, m=128 MB, p=2) with per-user salt and a server-side pepper.
Data is transmitted only over TLS 1.2 or higher; HSTS is preloaded for all production domains.
Sensitive operational secrets (API keys, signing keys, database credentials) are stored in approved secret stores; never committed to source control; never sent over chat or email.

3.2 Integrity

All write APIs require authentication and authorisation.
The audit log records every state-changing action; tampering with audit log entries is a disciplinary matter as well as a security incident.
Cross-vertical synchronisation messages are HMAC-signed with per-vertical keys; signing keys rotate on a documented cadence (see docs/operator-jwt-per-vertical.md).
Code changes flow through pull request with mandatory review. Infrastructure changes flow through OpenTofu plan-and-review. Direct writes to main are blocked by branch protection.

3.3 Availability

The platform is operated across two independent compute stacks (AWS Lambda in us-east-1, Scaleway Functions in fr-par) with health-checked failover.
Recovery objectives are defined in the Business Continuity & Disaster Recovery Plan.
Backups are encrypted, taken per vertical, and verified for integrity nightly via a real round-trip restore in DR scenario 22.
Service-level objectives (5xx rate, p95 latency, apex probe) are monitored with alerting and inline runbooks (docs/observability.md).

3.4 Identity and access

Multi-factor authentication is required for all production access and for all administrative actions.
Access is granted on a need-to-have basis (least privilege) and reviewed at hire, at role change, and at least quarterly.
The role-based access control model defines 8 organisation-level permissions and 25+ team-level permissions enforced at the application layer.
Privileged production access is logged. The admin-action audit log is retained for at least 12 months.
Session lifecycle is managed centrally: refresh tokens rotate on use, with family-based reuse detection that revokes the full family on detected reuse.

3.5 Cryptography

Cryptographic algorithms in production use are documented at /technology/encryption.
Implementations rely on the Noble libraries; the Wycheproof test vector corpus is vendored and runs in CI.
Key generation, storage, distribution, and destruction follow the documented procedures in the cryptography section above and in the operator runbooks.
Hybrid post-quantum encryption (RSA-OAEP-8192 + ML-KEM-1024) is used for all wrapping of recipient keys.

3.6 Change management

All code and infrastructure changes are version-controlled.
Every pull request requires review by an authorised reviewer before merge.
Production deployments are CI-driven only; manual production installs are prohibited.
Schema migrations are reviewed for safety (DR scenario 20 tests migration safety in CI).

3.7 Vendor and sub-processor management

The current sub-processor list is published at /legal/sub-processors.
Sub-processors are evaluated for security and privacy posture before onboarding, and re-evaluated at least annually.
Customers receive at least 30 days' notice before a new sub-processor is added or an existing one's role changes materially (per the DPA).

3.8 Logging, monitoring, and audit

Application-level audit logs capture access and modification events.
Observability telemetry (traces, logs, RED metrics) is exported to Grafana Cloud with three SLO alerts wired and runbooks attached.
Daily security-posture probes verify 16+ controls and publish a public attestation at /trust only when a control has been measured green for 30+ consecutive days.

3.9 Incident response

Security incidents are handled in accordance with the Incident Response Policy. Customers are notified without undue delay, and in any event within 72 hours, of any personal-data breach as required by the DPA.

3.10 Risk management

Glassbreak maintains a documented risk register. The register is refreshed at least annually and after every material change to the platform.
The most recent formal risk assessment is dated 27 May 2026 and is documented in docs/security-audit-2026-05-27.md (available redacted under NDA).
Identified risks are categorised, prioritised, and treated with documented mitigations or accepted with a recorded rationale.

3.11 Coordinated disclosure

Glassbreak welcomes reports from external security researchers under the published Coordinated Disclosure Policy. Reports may be sent to security@glassbreak.io and are triaged within 5 business days.

4. Roles and responsibilities

Security Officer — owns this policy, the Glassbreak risk register, and the operational ISMS. Approves every material change to the security control surface.
Engineering — responsible for implementing and operating the technical controls described in this policy and for evidencing them through the daily security-posture snapshot.
Workforce members — responsible for completing required training, complying with this policy and its dependent procedures, and reporting suspected incidents promptly.
Customers— responsible for managing their own organisation's configuration within the platform (members, roles, MFA enforcement, audit log retention) and for the content they submit.

5. Compliance and enforcement

Compliance with this policy is mandatory for all workforce members.
Violations are handled in accordance with the Sanctions & Disciplinary Policy.
Customers found to be misusing the platform (e.g. submitting unlawful content, attempting to bypass technical controls) are subject to suspension and termination under the Terms.

6. Exceptions

Exceptions to this policy require written approval by the Security Officer, documented in the risk register with a recorded expiry date and compensating controls. Open exceptions are reviewed at every annual policy review.

7. Review

This policy is reviewed at least annually and after every material change to the platform, the regulatory environment, or Glassbreak's operating context. The next scheduled review is 27 May 2027.

8. Related documents

Counter-signed PDF copy available on request to compliance@glassbreak.io.