ISMS Scope

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

1. Purpose

This document is the controlled scope statement for Glassbreak's Information Security Management System (ISMS). It is the artefact required by ISO/IEC 27001:2022 Clause 4, supporting the published Information Security Policy and forming the boundary against which the Statement of Applicability and the Risk Treatment Plan are drawn.

It defines the organisational context in which the ISMS operates, identifies the interested parties whose needs and expectations the ISMS must satisfy, sets the boundaries of what is and is not in scope, and enumerates the interfaces between Glassbreak and external services that cross those boundaries.

2. Organisational context

2.1 The organisation

Glassbreak is a software-as-a-service provider operating a zero-knowledge break-glass and secrets-sharing platform. The platform exists so that customer organisations can store, share, and recover their most critical credentials and coordinate emergency response, with the confidentiality of stored material guaranteed cryptographically rather than by trust in Glassbreak.

The organisation operates as a remote-first business with workforce members distributed across multiple jurisdictions. It holds no physical data centres of its own. All production workload runs on commercial cloud sub-processors documented at /legal/sub-processors.

2.2 Internal context

  • Mission. To provide a credential-recovery and secret-sharing service whose confidentiality guarantee does not depend on the operator being trustworthy.
  • Operating model. Cloud-native multi-stack deployment with continuous delivery, defined in docs/architecture.md.
  • Governance. Leadership approves all material policy and risk decisions. The Security Officer owns the ISMS and is the accountable owner for the controls catalogue.
  • Information assets. Customer ciphertext and metadata, source code, infrastructure-as-code, cryptographic keys, audit logs, workforce records, and business records.
  • Risk appetite. Low for confidentiality of customer data; moderate for availability of non-critical surfaces; the cryptographic design intends that even a complete compromise of the operator cannot disclose customer plaintext.

2.3 External context

  • Regulatory. EU GDPR, UK GDPR, Swiss FADP, US state privacy laws as applicable to customer data, the EU NIS2 Directive as it applies to digital service providers, and sector-specific frameworks (HIPAA, PCI DSS, FedRAMP) to the extent customers depend on them.
  • Standards. ISO/IEC 27001:2022 is the framing standard for this ISMS. SOC 2 (AICPA Trust Services Criteria), ISO/IEC 27017 (cloud), ISO/IEC 27018 (PII in public cloud), NIST SP 800-53 Rev 5, NIST SP 800-63B (digital identity), and OWASP ASVS are referenced where relevant.
  • Market. B2B SaaS sold primarily to security- and engineering-led teams in regulated industries; the customer base spans jurisdictions and verticals.
  • Threat landscape. Insider misuse, credential stuffing, account takeover, sub-processor compromise, supply-chain attack, targeted attack on cryptographic material, and disruption from sub-processor outage.

3. Interested parties

The following parties have legitimate interests in the operation and effectiveness of the ISMS. The needs and expectations of each are reviewed at least annually.

3.1 Customers (data controllers)

  • Expect that the confidentiality of submitted material is guaranteed by design and that Glassbreak cannot read it under any circumstance.
  • Expect availability of the service that meets the published recovery objectives in the BCP/DR plan.
  • Expect timely notification of incidents that affect them, per the Data Processing Agreement at /legal/dpa.
  • Expect that sub-processors are vetted, listed, and that material changes are announced in advance.
  • Expect that controls supporting their own compliance obligations (SOC 2, HIPAA, ISO 27001, GDPR) are documented at /trust.

3.2 Sub-processors

  • Expect that Glassbreak operates within the terms of their acceptable-use, security, and contractual policies.
  • Expect prompt notification of any incident affecting the sub-processor relationship.
  • Expect that Glassbreak does not use the sub-processor relationship in ways outside the agreed contract surface.

3.3 Regulators and supervisory authorities

  • Data-protection supervisory authorities under GDPR, UK GDPR, FADP, and equivalents — expect lawful processing, breach notification within statutory deadlines, and cooperation with investigations.
  • Sectoral regulators relevant to customers — expect that Glassbreak supports its customers in meeting their own obligations.
  • Tax and corporate authorities — expect lawful operation of the business in each jurisdiction.

3.4 Security researchers

  • Expect a documented coordinated disclosure route, prompt acknowledgement, honest triage, and recognition of good-faith research per the Coordinated Disclosure Policy.
  • Expect no legal action against good-faith research conducted within the published rules of engagement.

3.5 Leadership and investors

  • Expect that information-security risk is identified, quantified, treated, and reported in a way that supports business decision-making.
  • Expect that the ISMS programme cost is proportionate to the risk it controls and the value it unlocks (customer trust, enterprise procurement readiness, certification path).

3.6 Workforce

  • Expect clear, current, and proportionate policies that describe what is required of them and what protections they can rely on.
  • Expect that incidents are handled blamelessly with the aim of improving the system.
  • Expect fair, proportionate, and consistent application of the Sanctions & Disciplinary Policy.

3.7 The public

  • Expects that an organisation operating critical credential infrastructure publishes its commitments honestly and does not overstate its compliance posture.
  • Expects that incidents with public consequence are disclosed on the public status page and through the trust page.

4. Boundaries of the ISMS

4.1 In scope

  • The hosted Glassbreak platform — the production service exposed on the surfaces enumerated in section 5 below, including the application, API, database, audit log, object storage, and all infrastructure-as-code that defines them.
  • The supporting CI/CD pipeline — the source repository, the build and test pipelines, the release pipeline, the package registry, and any pre-production environments operated by Glassbreak.
  • The workforce — employees, contractors, advisors, and interns regardless of jurisdiction or working arrangement, to the extent of their work for Glassbreak.
  • Workforce endpoints — devices used by workforce members to access Glassbreak systems, including the controls in /policies/onboarding section 4 and /policies/offboarding section 5.
  • Operational records — the access register, the incident register, the credential-rotation log, the audit log, and the training records.
  • The ISMS itself — this scope document, the Statement of Applicability, the Risk Treatment Plan, and all published policies under /policies.

4.2 Out of scope

  • Customer-side configurationsof the platform — how individual customers structure their organisations, grant permissions to their members, enforce MFA on their accounts, set their audit-log retention, and integrate the platform into their own workflows. These are the customer's own ISMS scope.
  • The internal operation of sub-processors — sub-processors are assessed at the contract surface; their internal ISMS is in their own scope and is evidenced to Glassbreak by their own attestations (SOC 2, ISO 27001, DPA, etc.).
  • Downstream third parties of customers— organisations that customers choose to share, transmit, or federate Glassbreak material with. Those parties are governed by the customer's relationships, not by Glassbreak's.
  • Customer plaintext content.By cryptographic design, Glassbreak does not hold the keys to decrypt customer secret, contact, or message content. Plaintext therefore exists outside Glassbreak's technical scope of processing.
  • Personal devices and personal accounts of workforce members, except to the extent that the use of those devices or accounts for Glassbreak work is regulated by the Information Security Policy and the Acceptable Use Standard.
  • Customer-owned data submitted in violation of the Terms (for example, content not lawfully held by the customer) is governed by the Terms and the Acceptable Use expectations, not by this ISMS.

5. Surfaces in scope

The ISMS applies to the following operational surfaces. The authoritative architectural description, including the topology diagram and the failure matrix, is in docs/architecture.md.

  • Primary surface: glassbreak.io — fronted by Fastly with health-checked failover across the two compute stacks.
  • EU-direct backup surface: glassbreak.cloud — Scaleway compute and storage in fr-par, end-to-end EU stack, no CDN.
  • US-direct backup surface: glass-break.com — AWS Lambda and S3 in us-east-1, no CDN.
  • API endpoints on the equivalent api.* hostnames for each domain.
  • The two compute stacks: AWS Lambda Function URLs (api/aws/) and Scaleway Functions (api/scaleway/).
  • The two databases: Neon Postgres in aws-us-east-1 and Scaleway Managed Database in fr-par.
  • Object storage on each vertical.
  • Cross-vertical synchronisation transport — HTTPS push with HMAC signatures between the verticals; no shared queue.
  • The CI/CD pipeline hosted on GitHub and operated through GitHub Actions.
  • The observability surface at Grafana Cloud (Tempo, Loki, Mimir) and the daily security-posture snapshot publication at /trust.
  • The future fourth surface, glassbreak.dev, will be brought into scope when the Phase 8 hard-disconnect path is provisioned.

6. Information classes

The ISMS recognises the following classes of information; each class carries its own handling rules in the Acceptable Use Standard and inherits the controls catalogued in the Statement of Applicability.

  • Customer plaintext content (Class P) — secret, message, and contact content for which Glassbreak does not hold decryption keys. Out of cryptographic scope of processing.
  • Customer ciphertext and metadata (Class CT) — encrypted blobs and the metadata required to address, route, and audit them. Processed by Glassbreak in scope of the ISMS.
  • Account and contact data (Class A) — workforce-readable personal data such as email addresses, organisation membership, and billing identifiers.
  • Cryptographic key material (Class K)— signing keys, HMAC keys, pepper material, and other secrets used to operate the platform's integrity guarantees.
  • Audit and observability data (Class L) — application audit log, request logs, traces, RED metrics.
  • Workforce and business records (Class W) — employment records, access register entries, financial records, customer agreements.
  • Source code and infrastructure-as-code (Class S) — the repository, package metadata, and IaC modules.

7. Interfaces with external services

The following interfaces cross the boundary of the ISMS. Each interface has a documented purpose, an identified counter-party, a defined data class moving across it, and a control reference in the Statement of Applicability.

7.1 Compute and storage sub-processors

  • AWS — Lambda compute, S3 object storage, EventBridge scheduling, IAM, CloudWatch logs (Class CT, A, L, K). Documented at /legal/sub-processors.
  • Scaleway — Serverless Functions, Object Storage, Managed PostgreSQL, Serverless SQL, Edge Services (Class CT, A, L, K).
  • Neon — managed Postgres on AWS infrastructure for the Lambda vertical (Class CT, A, L).
  • Fastly — edge routing and TLS termination on the primary glassbreak.io surface (Class CT, A in flight only).

7.2 Customer-facing transactional services

  • Stripe — payment processing; receives Class A (billing identifiers, card details held by Stripe).
  • Postmark / SES — transactional email delivery; receives Class A (recipient address, transactional content).
  • Twilio — SMS-based MFA and notifications; receives Class A (recipient number, message text).

7.3 Engineering and observability services

  • GitHub — source-code hosting, issue tracking, CI/CD via GitHub Actions, container registry (Class S, no customer data).
  • Grafana Cloud — observability ingestion (Tempo, Loki, Mimir) for traces, logs, RED metrics (Class L).

7.4 Domain, DNS, and registrar services

  • Registrar (Porkbun, Gandi, DNSimple per domain) — no Glassbreak information beyond domain ownership records.
  • DNS authorities (Route 53, DNSimple, Gandi LiveDNS, deSEC, Porkbun DNS) — public DNS records only.

7.5 Customer interfaces

  • The HTTPS interface at each domain. All requests cross this interface with at least TLS 1.2 termination on the customer side.
  • The cross-vertical sync transport — HTTPS push with HMAC signatures between AWS and Scaleway verticals operated by Glassbreak (entirely internal to the ISMS but logically spans both halves of the in-scope surface).

8. Internal interfaces between in-scope parts

  • Application-to-database calls within each vertical.
  • Application-to-object-storage calls within each vertical.
  • Application-to-sub-processor outbound calls (Stripe webhooks, Postmark sends, Twilio sends).
  • CI/CD pipeline deployments from GitHub Actions into the AWS and Scaleway provider planes.
  • Workforce console access into provider planes (AWS, Scaleway, Fastly, Neon, etc.) for break-glass operational tasks; all such access is MFA-enforced, logged, and reviewed under the Information Security Policy section 3.4.

9. ISMS dependencies on external attestations

Where the ISMS depends on a sub-processor for the operation of a control (for example, physical security of data centres), the operation of that control is evidenced by the sub-processor's own attestation (SOC 2, ISO 27001, or equivalent). Where a sub-processor's attestation lapses or is downgraded, the gap is recorded in the risk register and either replaced with an alternative sub-processor or accepted with a documented rationale and compensating controls.

10. Exclusions and rationale

  • Physical office security controls are excluded from the in-scope surface because Glassbreak operates no dedicated office estate. Where workforce members work from personal premises, the controls applicable are limited to the device and account controls applicable to remote working, as defined in the Acceptable Use Standard.
  • Industrial control systems are not in scope; Glassbreak does not operate any.
  • The customer's own ISMS is excluded; customers operate their own scope on their own side of the interface.

11. Review

This scope document is reviewed at least annually and after any of the following: a material change to the platform topology described in docs/architecture.md; the addition or removal of a sub-processor in a tier that changes the control surface; a material change to the regulatory environment; an incident that reveals an in-scope element that was treated as out of scope; or the start of a formal ISO 27001 certification engagement. The next scheduled review is 27 May 2027.

12. Related documents

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

Stay Updated

Get product updates and security insights. No spam, unsubscribe anytime.

We respect your privacy. See our privacy policy.