FedRAMP SSP Summary

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

1. Status of this document

This is a summary of what a future Glassbreak FedRAMP Moderate System Security Plan (SSP) would contain. It is not the SSP itself. Glassbreak is not currently FedRAMP authorised; the live status of the authorisation question is published at /trust/fedramp, including the trigger conditions that would cause Glassbreak to begin the authorisation work.

The purpose of this summary is to give federal and federal-adjacent buyers an honest preview of the structure and substance that a Glassbreak SSP would carry — so that the decision to pursue authorisation can be informed by what is already in place against the NIST SP 800-53 Rev 5 Moderate baseline rather than by speculation.

2. What an SSP is

A FedRAMP System Security Plan is the central document of a FedRAMP authorisation package. It describes the system, its boundary, the data it processes, the people who operate it, the security controls in place, and the responsibilities shared between the cloud service provider, the leveraged infrastructure, and the customer. It is the artefact that the Third Party Assessment Organization (3PAO) tests against and that the agency Authorising Official (AO) reads to decide whether to issue an Authority to Operate (ATO).

3. System identification

A future Glassbreak SSP would identify the system as follows. The detail here is consistent with the publicly described architecture (docs/architecture.md) and with the published sub-processor list.

  • System name. Glassbreak — hosted zero-knowledge break-glass and secrets-sharing platform.
  • System owner. Glassbreak (the legal entity behind the service).
  • FIPS 199 categorisation.Moderate impact across confidentiality, integrity, and availability. Justified by the system's role in storing and recovering customer-controlled credentials.
  • Service model. Software as a Service (SaaS).
  • Deployment model. A future authorised deployment would be a dedicated environment hosted in a FedRAMP-authorised cloud region (AWS GovCloud is the realistic candidate). The commercial product would remain a separate deployment under separate authorisation — see /trust/fedramp for the rationale.
  • Authorising Official. To be named at the time of sponsorship; not pre-named.

4. System boundary

The SSP would describe the authorisation boundary — everything inside the boundary is in scope of the assessment, everything outside is leveraged or external.

4.1 In the boundary

  • The application code that runs the platform — the Glassbreak API, the web application, the supporting workers and crons, the cross-vertical sync transport.
  • The infrastructure-as-code that defines and provisions the environment.
  • Application-tier services operated by Glassbreak inside the authorised cloud (compute, container images, application configuration).
  • The application database holding customer ciphertext and metadata.
  • Object storage holding customer uploads.
  • The audit log, observability surface, and security telemetry generated by the application tier.
  • The release pipeline operated by Glassbreak (a FedRAMP-tailored pipeline, separate from the commercial CI/CD per /trust/fedramp).
  • Workforce identity and access management for personnel authorised to operate the system.

4.2 Leveraged authorisations

A FedRAMP authorisation can leverage the prior authorisation of underlying services rather than re-assessing them. Glassbreak's SSP would expect to leverage:

  • AWS GovCloud (or equivalent FedRAMP-authorised cloud region) — FedRAMP High authorised infrastructure providing compute, networking, storage, identity, and monitoring primitives.
  • The managed database, object storage, and related primitives on the authorised cloud region — leveraged for their respective FedRAMP listings where available; otherwise re-assessed in scope.
  • FedRAMP-listed identity providers if used (for example, the agency IdP issuing PIV/CAC credentials).

Sub-processors that do not hold FedRAMP authorisations (Stripe, Postmark, Twilio, Grafana Cloud, GitHub, Fastly, Scaleway, Neon) would either be replaced with FedRAMP- authorised equivalents on the authorised boundary, removed from the FedRAMP product path entirely, or — for narrowly scoped non-PII processing — accepted as a non-FedRAMP connection with explicit acknowledgement and compensating controls.

4.3 External services

  • Customer identity providers (where federated authentication is in use).
  • Customer-side endpoints that consume the API.
  • External vulnerability disclosure channels.

5. Network and data-flow references

The SSP would include the Authorization Boundary Diagram (ABD), the Network Diagram, and the Data Flow Diagram (DFD) as required by the FedRAMP template. The structure of these diagrams would follow the publicly described topology in docs/architecture.md, adjusted for the FedRAMP-only deployment:

  • The two-stack commercial architecture is notthe FedRAMP architecture — the FedRAMP deployment is a dedicated environment on a single authorised cloud, with its own redundancy strategy within that cloud's region pair.
  • Cross-vertical sync (the HMAC transport between AWS and Scaleway in the commercial product) would not cross the FedRAMP boundary; the FedRAMP environment is self-contained.
  • The Authorization Boundary Diagram would explicitly show every external connection (customer browser / client, customer IdP, external advisory feeds) and every leveraged service inside the cloud authorisation.
  • The Data Flow Diagram would show the flow of Controlled Unclassified Information (CUI) from ingestion through processing, storage, and disposal.

6. Security controls implementation summary

The SSP would describe the implementation of every control in the NIST SP 800-53 Rev 5 Moderate baseline. For brevity, this summary defers the per-control narrative to the family table at /trust/fedramp and highlights here only the families that materially differ from the commercial product baseline.

  • SC — System and Communications Protection. FIPS 140-3 validated cryptographic modules are required; the commercial product's Noble libraries are not FIPS-validated and would be substituted for the FedRAMP deployment.
  • IA — Identification and Authentication. PIV/CAC authentication accepted for federal users; NIST SP 800-63B compliant identity assurance levels at the relevant level for the system categorisation.
  • PS — Personnel Security. Public-trust investigation level applied to workforce members with access to the FedRAMP environment; US-citizens-only personnel access per FedRAMP expectations for the relevant data categories.
  • PE — Physical and Environmental Protection. Leveraged from the FedRAMP-authorised cloud region; non-US sub-processor regions are not in the boundary.
  • SA — System and Services Acquisition. Software supply chain governed by the Supply Chain Risk Management Plan extended with FedRAMP-specific expectations (FedRAMP-listed services preferred where available; SBOM published per release; signed releases enforced).
  • CA — Assessment, Authorisation, and Monitoring.The SSP, SAR, POA&M, and continuous-monitoring (ConMon) plan are FedRAMP artefacts that would be produced as part of the authorisation work; they do not exist today (see /trust/fedramp).
  • SR — Supply Chain Risk Management. Extends the existing Supply Chain Risk Management Plan with FedRAMP-specific provenance, foreign-ownership-influence-or-control (FOCI) screening, and SBOM publication.

Families that the commercial product already meets at a FedRAMP-compatible standard — CM (Configuration Management), CP (Contingency Planning), MP (Media Protection), PT (PII Processing and Transparency), and the bulk of SC — would carry over with minor adjustments for the dedicated environment.

7. Authorisation boundary statement

The authorisation boundary is the set of components for which Glassbreak holds direct responsibility under the authorisation. Components outside the boundary are either leveraged from prior authorisations (with the inheritance explicitly documented) or external services that the SSP identifies and excludes.

A key boundary decision for Glassbreak is that the authorisation would cover a dedicated FedRAMP deployment rather than the commercial product. Code reuse between the two is permitted (the same source code can produce both deployments) but the running environments, credentials, sub-processor relationships, and operational staff for the FedRAMP deployment are scoped to that authorisation only.

8. Customer Responsibility Matrix (CRM) placeholder

The CRM enumerates which controls the customer must operate, which Glassbreak operates, and which are shared. The full CRM would be produced as part of the SSP authoring; a representative summary of the responsibility split is:

  • Customer-operated.Identity and access management within the customer's own organisation on the platform; enforcement of MFA on customer-side accounts; configuration of audit-log retention for the customer's organisation; governance of which workforce members of the customer have which platform roles; customer-side incident response for events affecting the customer's organisation.
  • Glassbreak-operated.The platform infrastructure, all the application-tier controls in the SSP, the operational personnel security controls on Glassbreak workforce, the cryptographic implementation, the backup and recovery procedures, sub-processor management, and the incident response procedure on Glassbreak's side.
  • Shared.Vulnerability management (Glassbreak addresses platform vulnerabilities; customer is responsible for vulnerabilities in any integration code they operate); incident response (Glassbreak detects and responds to platform incidents; customer detects and responds to incidents in their own use of the platform); audit (Glassbreak publishes audit data to the customer; the customer is responsible for collecting it on the customer's cadence).
  • Inherited from the leveraged authorisation. Physical and environmental controls; cloud-platform identity primitives; cloud-platform network primitives; cloud-platform monitoring substrate.

9. Continuous Monitoring (ConMon) summary

The SSP would commit Glassbreak to the standard FedRAMP ConMon obligations:

  • Monthly vulnerability scanning of the operating environment with remediation against FedRAMP timelines.
  • Monthly POA&M updates submitted to the Authorising Official.
  • Annual independent assessment by the 3PAO covering a sample of controls.
  • Significant-change requests submitted ahead of any material change to the system.
  • Annual incident-response exercise; integration with US-CERT incident-reporting where applicable.

10. What still needs to be produced

If Glassbreak begins formal FedRAMP work, the artefacts listed below would be produced. They do not exist today; this is the gap relative to a complete authorisation package.

  • Full FedRAMP-template SSP (this is a summary, not the SSP).
  • Authorization Boundary Diagram, Network Diagram, Data Flow Diagram in the FedRAMP template.
  • Information System Contingency Plan in the FedRAMP template (building on the existing BCP/DR plan).
  • Incident Response Plan in the FedRAMP template (building on the existing IR Policy).
  • Configuration Management Plan, Continuous Monitoring Plan, Privacy Impact Assessment, e-Authentication Plan, Rules of Behaviour, and the other FedRAMP template documents.
  • Complete Customer Responsibility Matrix.
  • Per-control implementation statements for all 325 Moderate baseline controls.
  • 3PAO Security Assessment Plan (SAP) and Security Assessment Report (SAR).
  • Initial POA&M with all identified findings and remediation timelines.

11. Why this document exists

Buyers in the federal and federal-adjacent space need to understand a vendor's realistic position before they commit to procurement work. Publishing a summary of what an SSP would say lets a prospective sponsor see what is already in place and what would have to be built; it avoids the alternative of either silence (uninformative) or claiming FedRAMP readiness without an In Process listing (which the live /trust/fedramp page explicitly disclaims).

12. Disclaimer

This document is a public-safe summary of an artefact that does not yet exist. It is not a substitute for the SSP and must not be relied on as evidence of FedRAMP authorisation. FedRAMP authorisation is a formal process with a specific evidentiary record; only an active In Process or Authorised listing on the FedRAMP Marketplace constitutes that record. The live status, including whether Glassbreak holds any such listing, is published at /trust/fedramp.

13. Review

This summary is reviewed at least annually and after any material change to the architecture, the sub-processor mix, or Glassbreak's position on the FedRAMP question as published at /trust/fedramp. The next scheduled review is 27 May 2027.

14. Related documents

If federal use is a material part of your buying decision, please write to compliance@glassbreak.io. A redacted preview of the implementation evidence supporting this summary is available under NDA.

Stay Updated

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

We respect your privacy. See our privacy policy.