SA-9(6): Organization-controlled Cryptographic Keys

SA-9(6) requires you to keep exclusive control of the cryptographic keys used to protect your data when that data is stored or transmitted through an external system (for example, a cloud or third-party hosted platform). Operationally, you must design key ownership, generation, storage, access, rotation, and revocation so the third party cannot independently decrypt your data. ¹

Key takeaways:

• You pass SA-9(6) by proving the third party cannot access or misuse your encryption keys without your authorization. ¹
• “Exclusive control” is an operating model: key lifecycle controls, access governance, and contracts must align. ¹
• Evidence matters as much as design; plan for assessor-ready artifacts from day one. ¹

SA-9(6): organization-controlled cryptographic keys requirement sits at the intersection of third-party risk management, cloud security architecture, and practical audit readiness. You will run into it any time encrypted organizational data leaves your direct system boundary and lands in an “external system,” such as SaaS, PaaS, IaaS, managed file transfer, backup-as-a-service, or a hosted data analytics platform. The control is short, but implementation is not: assessors look for “exclusive control” as an end-to-end property of your design and operations, not as a single checkbox like “data is encrypted.”

Treat this requirement as a key ownership and separation-of-duties problem. If the external provider can obtain, derive, export, or reconstitute your keys (or use their privileged access to decrypt on your behalf without your approval), you have a gap. If your organization controls keys through your own KMS/HSM, or through customer-managed keys where you retain unilateral ability to deny decryption, you are in the right neighborhood.

This page gives you requirement-level steps to implement SA-9(6) quickly: scope what “external system” means in your environment, choose a key control model, harden key lifecycle operations, bind it all into contracts and procedures, and retain the artifacts auditors ask for.

Regulatory text

Requirement (verbatim excerpt): “Maintain exclusive control of cryptographic keys for encrypted material stored or transmitted through an external system.” ¹

Operator interpretation: If your data is encrypted and stored or transmitted using a third party’s systems, your organization must keep exclusive control of the encryption keys that protect that data. Exclusive control means the third party does not have independent ability to decrypt the data (including via staff access, break-glass processes, platform-level key escrow, or “we can recover it for you” features), except under conditions you explicitly authorize and can revoke. ¹

Plain-English interpretation (what “exclusive control” means in practice)

You meet SA-9(6) when all of the following are true:

• Key ownership: Your organization is the key custodian. The third party is not the key owner and cannot claim shared ownership through default platform controls. ¹
• Key access control: Only approved organizational identities (or tightly controlled service principals you manage) can use keys for encrypt/decrypt operations. ¹
• Key non-export/containment: Keys are stored in a way that prevents the third party from extracting them in plaintext, and prevents unauthorized copying or reconstruction. ¹
• Key lifecycle authority: Your organization controls rotation, disabling, revocation, deletion, and incident-driven actions (for example, shutting off decryption if the relationship ends). ¹

A useful test for “exclusive control”: If you terminate the third party relationship today, can you immediately prevent that third party from decrypting any newly captured ciphertext, and can you render existing encrypted data unreadable to them without your cooperation?

Who it applies to (entity and operational context)

Entity scope

• Federal information systems and organizations implementing NIST SP 800-53 controls.
• Contractors and other organizations handling federal data in systems where NIST SP 800-53 is flowed down or used as the control baseline. ¹

Operational scope

• Any workflow where organizational data is stored in a third-party environment (SaaS records, object storage, managed databases, ticketing systems, external backup).
• Any workflow where organizational data is transmitted through a third party (managed message queues, MFT gateways, API intermediaries, CDN/edge encryption services).
• Any “security feature” that encrypts data but defaults to provider-managed keys, unless you can prove the provider cannot decrypt without you. ¹

What you actually need to do (step-by-step)

1) Inventory external systems and the data paths they touch

Create a scoped list of external systems that store or transmit sensitive or regulated data. For each, document:

• Data types (CUI, PII, secrets, logs, intellectual property)
• Storage locations (region/tenant/project)
• Encryption points (client-side, application-level, storage-level, transport-level)
• Key manager of record (your KMS/HSM vs provider-managed) ¹

Deliverable: “External System Crypto Key Scope Register” tied to your system boundary and data flow diagrams.

2) Choose a key control model per external system

Use a decision matrix. Default to the strongest model feasible for the service:

Model	Who controls keys?	Typical pattern	SA-9(6) fit
Client-side / application-level encryption	You control keys entirely	Encrypt before sending to third party	Strongest, simplest to argue
Customer-managed keys (CMK) in provider KMS with strict controls	You control key policy and can disable	“Bring your own key” style	Often acceptable if provider cannot decrypt without your authorization
Provider-managed keys	Third party controls keys	Default at-rest encryption	Usually hard to justify as “exclusive control” without compensating design

Your job is to document why the chosen model still preserves exclusive control, and what prevents independent decryption by the third party. ¹

3) Implement key lifecycle controls you can prove

Minimum operational procedures to define and run:

• Key generation: Keys created under your authority (KMS/HSM policies, approved algorithms, access approvals).
• Key storage: Keys stored in controlled key stores (HSM/KMS) with separation of duties.
• Key usage control: Restrict decrypt operations to named roles; require change control for policy changes.
• Rotation: Rotate on a defined schedule and on trigger events (compromise suspicion, admin turnover, vendor offboarding).
• Revocation/disable: Ability to disable keys quickly as an offboarding and incident response action.
• Logging/monitoring: Key management audit logs enabled; alerts for policy changes, key disable/enable, and unusual decrypt patterns. ¹

Practical control owner mapping:

• Security Engineering: technical implementation (KMS/HSM, IAM)
• GRC/Compliance: requirement mapping, evidence, control testing
• Procurement/Legal: contract language and third-party obligations
• Application Owners: data path validation and exception handling

4) Bind “exclusive control” into third-party contracts and operating terms

SA-9(6) is not satisfied by architecture alone if contracts allow the third party to regain access. Ensure your third-party agreements cover:

• No key escrow or provider-held copies that enable decryption without your approval
• Explicit delineation that keys are organization-controlled
• Support boundaries for lawful requests and how your organization is involved
• Offboarding commitments: secure deletion, confirmation of key disablement options, return of encrypted data
• Breach notification and cooperation provisions tied to crypto/key events ¹

5) Create an assessor-ready “key control story” per external system

For each external system, prepare a short narrative plus diagrams:

• Where encryption happens
• Which key protects which data set
• Who can call decrypt
• How you rotate and revoke
• What happens if the third party is compromised
• What you do during offboarding ¹

This is where teams often stall. Daydream (as a working practice, not a tool pitch) helps by mapping SA-9(6) to a single control owner, a repeatable procedure, and a recurring evidence set so you do not rebuild the story every audit cycle. ¹

Required evidence and artifacts to retain

Keep evidence that proves exclusive control in design and operation:

Governance + scope

• External System Crypto Key Scope Register
• Data flow diagram showing encryption boundaries and key manager
• Control narrative for SA-9(6) mapped to each external system ¹

Technical configuration

• KMS/HSM configuration exports or screenshots (key policies, key ownership, non-export settings where applicable)
• IAM role mappings for key admin vs key user vs auditor roles
• Proof of customer-managed key configuration for each external system that claims CMK/BYOK ¹

Operational runbooks

• Key rotation procedure and execution records
• Key disable/revocation runbook (incident + offboarding)
• Access request and approval records for key admin privileges ¹

Monitoring

• Key management audit logs enabled (log source list, retention setting)
• Sample alerts/tickets for key policy change or unusual decrypt activity ¹

Third-party documentation

• Contract clauses or addenda on key control and decryption limits
• Vendor/third party architecture attestations or service descriptions that explain key custody ¹

Common exam/audit questions and hangups

Assessors tend to focus on a few friction points:

• “Show me the keys are exclusively controlled by you.” Expect to demonstrate the key policy and who can perform decrypt, not just that encryption is enabled. ¹
• “Can the third party support team decrypt your content?” If the answer is “yes, in some cases,” you need tight conditions, approvals, and technical prevention where feasible.
• “How do you offboard?” Auditors want to see you can shut off decryption and have a clean exit path.
• “Where is the boundary?” If data transits multiple third parties (SaaS + integration platform + logging provider), SA-9(6) scope expands quickly. ¹

Frequent implementation mistakes (and how to avoid them)

1. Assuming “encryption at rest” equals compliance. Provider-managed at-rest encryption often leaves decryption power with the provider. Fix: document key custody and enforce customer-controlled policies. ¹

2. No ability to revoke quickly. Teams can rotate but not disable, or disabling breaks unknown dependencies. Fix: test disablement in a controlled environment and document a break-glass plan owned by your org. ¹

3. Key admin sprawl. Too many humans have key admin rights, including contractors. Fix: separate key admin from key user roles; require approvals and periodic access review for privileged roles. ¹

4. Contract drift. Your architecture says CMK, but the contract allows support decryption “as needed.” Fix: reconcile paper and practice during procurement and renewals. ¹

5. Evidence gaps. Controls exist but no one captures artifacts. Fix: assign an evidence owner and recurring collection tasks; Daydream-style control mapping is the simplest way to keep this from becoming a quarterly scramble. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for SA-9(6), so treat this as an assessment-driven requirement rather than one with a case law playbook in this page. ¹

Risk still concentrates in predictable places:

• Confidentiality failure: If the third party can decrypt, their compromise can become your breach scenario.
• Legal/process risk: If a third party can produce decrypted content under external compulsion without your control, you may lose governance over disclosure.
• Exit risk: Without key disablement authority, offboarding becomes negotiation instead of execution. ¹

Practical 30/60/90-day execution plan

First 30 days: establish scope and ownership

• Assign a control owner and named technical implementer for SA-9(6). ¹
• Build the External System Crypto Key Scope Register for your highest-risk external systems first.
• Identify which systems use provider-managed keys and flag them for remediation or exception handling.
• Draft a standard SA-9(6) control narrative template and an evidence checklist.

Days 31–60: remediate design gaps and lock in contracts

• Move priority systems to client-side encryption or customer-managed keys where feasible.
• Implement key policies, role separation, and logging for key events.
• Add or amend contract language for key custody, decryption boundaries, and offboarding support.
• Run a tabletop: “Third party compromise” and “Vendor offboarding,” focused on key disablement and evidence capture.

Days 61–90: operationalize and make it audit-repeatable

• Execute at least one rotation or rekey activity for scoped systems and retain the evidence.
• Implement periodic access reviews for key admin roles and document results.
• Build an assessor-ready package per external system: diagrams, policies, configs, logs, and contract excerpts.
• If you manage many third parties, implement a Daydream-style mapping so SA-9(6) evidence collection becomes a recurring task with clear owners and due dates. ¹

Frequently Asked Questions

Does SA-9(6) require customer-managed keys for every cloud service?

SA-9(6) requires exclusive control of keys, not a specific technology choice. If a service cannot support customer-controlled keys, you may need client-side encryption, a compensating design, or a documented exception with risk acceptance. ¹

If a SaaS provider says “we encrypt your data,” is that enough?

Usually you still need to validate who controls the keys and whether the provider can decrypt independently. Ask for details on key custody, privileged support access, and your ability to disable decryption. ¹

What counts as an “external system”?

Any system outside your direct administrative control that stores or transmits your encrypted data qualifies, including SaaS, managed hosting, and third-party integration services. Scope should follow the data path, not just the primary vendor contract. ¹

How do auditors typically verify “exclusive control”?

They commonly review key policies, role assignments, and logs for key usage and key policy changes, then reconcile that with architecture diagrams and contract terms. Your evidence needs to show the third party cannot decrypt without your authorization. ¹

What if the provider needs break-glass access for support?

Treat that as a high-risk design. If it cannot be eliminated, require documented approvals, tight time bounds, strong logging, and contractual limits, and prove you can revoke access and disable keys. ¹

What artifacts should I collect continuously rather than during audit season?

Keep an always-current scope register, current key policies and IAM role membership, key event logs, and completed access reviews. Also retain change tickets for key rotations, policy changes, and offboarding events. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON