SC-13: Cryptographic Protection

To meet the sc-13: cryptographic protection requirement, you must decide where cryptography is required in your system (data at rest, data in transit, and sensitive processing paths), then implement approved encryption, key management, and operational controls with auditable evidence. Operationalize SC-13 by defining crypto use cases, standardizing configurations, and proving continuous compliance through logging, inventories, and change control. ¹

Key takeaways:

• SC-13 starts with a decision: determine what needs cryptographic protection and where it applies in your environment. ²
• Auditors will focus on key management, algorithm choices, configuration consistency, and evidence that crypto is enforced (not “available”). ¹
• Your fastest path is a crypto standard + scoped implementation plan + recurring evidence bundle mapped to a named control owner. ¹

SC-13 sits in the System and Communications Protection family and is one of the first controls assessors use to test whether your security program is operational, not aspirational. Encryption is easy to claim and hard to prove because “we support TLS” or “the database has encryption” is not the same as “all in-scope data paths are encrypted with approved configurations, keys are protected, and exceptions are governed.”

The excerpt you are given is brief, but it points to the core operator task: you must determine the cryptographic protection needs for your system, then implement them in a way that can be assessed. ² That determination step is where many teams fail: they encrypt some things (often endpoints and a few databases) while missing backups, logs, message queues, file shares, admin channels, inter-service traffic, or third-party data exchanges.

This page is written for a Compliance Officer, CCO, or GRC lead who needs to drive SC-13 to closure quickly: define scope, assign owners, set crypto standards, force encryption through configuration and architecture, and build an evidence pack that survives audits and incident scrutiny. ¹

sc-13: cryptographic protection requirement — plain-English meaning

SC-13 requires you to make an explicit decision about where cryptographic protections are needed in your system and then implement cryptography accordingly. Practically, that means:

• Identify the data and communications that require protection.
• Define what “approved cryptography” means in your environment (algorithms, protocols, key lengths where relevant, libraries, modules, and configurations).
• Enforce encryption in those places through technical controls and guardrails.
• Manage cryptographic keys securely across their lifecycle.
• Keep evidence that proves encryption is in place and stays in place through change. ¹

Regulatory text

Excerpt: “Determine the {{ insert: param, sc-13_odp.01 }} ; and” ²

Operator interpretation: SC-13 is not only an engineering task. It is a governance task that starts with a determination: you must define the system’s cryptographic protection requirements (what must be encrypted, under what conditions, and using what standards) and then drive implementation and evidence around that decision. Your assessment outcome will depend on whether your determination is documented, reasonable for the system risk, and consistently implemented. ¹

Who SC-13 applies to

Entity scope

• Federal information systems.
• Contractor systems handling federal data. ²

Operational scope (what auditors usually treat as “in scope”)

• Data at rest: databases, object storage, file shares, endpoints, VM disks, container volumes, backups, snapshots, and exported reports.
• Data in transit: user-to-app, service-to-service, admin access (SSH/RDP), API calls, message buses, and third-party integrations.
• Cryptographic key management services and secrets stores.
• CI/CD and infrastructure-as-code pipelines that set encryption flags and TLS policies.
• Third-party connections where your system sends, receives, or processes covered data.

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

Use this as a control-implementation runbook. Keep each step tied to evidence.

1) Name the SC-13 control owner and draw the boundary

• Assign a single accountable owner (often Security Engineering or Platform Security) and document supporting teams (Infrastructure, AppSec, IAM, Data, IT).
• Define the system boundary: environments, accounts/subscriptions, networks, and major applications.
• Produce a scoping statement that answers: “Which data types and which flows are covered?” ¹

2) Build a “crypto coverage map” (data types × locations × flows)

Create a table (you can start in a spreadsheet) with columns:

• Data type (e.g., PII, authentication secrets, regulated data, logs containing sensitive fields)
• Location (DB, object store, endpoint, backup repository, SaaS)
• Flow (browser → app, app → DB, app → third party, admin access)
• Required control (encryption at rest, TLS, field-level encryption, tokenization)
• Enforcement mechanism (policy, config, gateway)
• Exception? (yes/no) with expiry and risk acceptance owner

This turns “we encrypt” into an auditable inventory aligned to the “determine” requirement. ²

3) Publish a cryptographic standard that engineers can follow

Write a short, enforceable standard that covers:

• Approved protocols for transit protection (for example, TLS configurations) and where they are mandatory.
• Approved at-rest mechanisms per platform (cloud-native encryption, database TDE, disk encryption).
• Approved crypto libraries/modules and rules for custom cryptography (generally prohibited without review).
• Key management expectations: where keys live, how access is granted, rotation approach, and separation of duties.
• Minimum configuration baselines (disable weak protocol versions/ciphers where applicable, enforce certificate validation, prohibit plaintext fallbacks). ¹

Keep it concrete: “Use X service/setting for Y workload” beats abstract principles.

4) Enforce encryption in transit by default

Operational controls that auditors recognize quickly:

• Central TLS policy for ingress (load balancers, API gateways, service mesh where applicable).
• Certificate management process (issuance, renewal, revocation) with ownership and monitoring.
• Controls to prevent plaintext traffic on sensitive networks (security groups/firewalls + service configuration).
• Tests: automated checks in CI/CD for TLS settings, plus periodic scanning results retained as evidence. ¹

5) Enforce encryption at rest across storage classes (including backups)

Prioritize the “forgotten” areas:

• Backups/snapshots: prove they are encrypted and keys are controlled.
• Logs: encryption at rest in your log platform and protected export paths.
• Endpoints and admin workstations: disk encryption with centralized policy where applicable.
• Data exports and analytics extracts: ensure encryption persists outside primary systems. ¹

6) Implement key management lifecycle controls

Assessors will test key management more than algorithm trivia.

• Centralize keys in a managed KMS/HSM where feasible, and document exceptions.
• Define who can create, use, rotate, disable, and delete keys.
• Enforce separation of duties for key administration vs system administration where practical.
• Log key access and administrative actions, and retain logs per your logging standard. ¹

7) Govern exceptions without breaking delivery

You will have legacy systems and third parties that cannot meet your standard immediately.

• Create an exception template: scope, compensating controls, expiry, risk acceptance, remediation plan.
• Require Security review and time-bound approvals.
• Track exceptions in a register that you can produce in an audit. ¹

8) Tie SC-13 to change control and continuous monitoring

SC-13 fails over time if encryption is not drift-resistant.

• Add encryption checks to infrastructure-as-code and policy-as-code.
• Require security approval for changes that touch TLS termination, key policies, crypto libraries, or data stores.
• Define recurring evidence pulls (configs, KMS policies, scans, logs, exception register). ¹

Where Daydream fits (practical, not theoretical)

If your gap is “we do encryption but can’t prove it,” use Daydream to map SC-13 to a named control owner, a repeatable implementation procedure, and a recurring evidence bundle so you can answer auditors with consistent artifacts instead of one-off screenshots. ²

Required evidence and artifacts to retain (audit-ready)

Keep evidence tied to the crypto coverage map and your standard.

Core artifacts

• SC-13 control narrative: scope, owner, how crypto requirements were determined, and how compliance is maintained. ¹
• Cryptographic standard/baseline (versioned) and approval record. ¹
• Crypto coverage map (data/flows matrix) and current exception register. ²

Technical evidence (representative, not exhaustive)

• TLS configuration exports for gateways/load balancers/service mesh, plus change history. ¹
• Storage encryption settings for databases, buckets, disks, and backups, with key identifiers redacted as needed. ¹
• KMS/HSM policies, key inventory, access control lists/roles, and admin activity logs. ¹
• CI/CD guardrails: policy checks or pipeline controls that prevent noncompliant deployments. ¹
• Incident tickets or problem records for crypto-related findings and remediation actions. ¹

Common exam/audit questions and hangups

Expect these and pre-answer them in your narrative and evidence bundle:

1. “How did you determine what requires encryption?” Show the crypto coverage map and data classification linkages. ²
2. “Is encryption enforced or optional?” Provide policy enforcement points and “deny-by-default” configurations. ¹
3. “Where are keys stored and who can access them?” Provide KMS/HSM design, roles, and logs. ¹
4. “How do you prevent plaintext traffic between services?” Show network controls plus service configuration evidence. ¹
5. “What about backups, exports, and logs?” Produce explicit evidence for each. These are common gaps. ¹
6. “How do you manage exceptions?” Show the exception register with approvals and expiry. ¹

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails audits	What to do instead
“TLS supported” without proof of enforcement	Support does not equal configuration compliance	Export configurations and show policies that block weak settings. 1
Encrypting databases but not backups/snapshots	Data copies often contain the same sensitive data	Treat backups as first-class scope items with their own evidence. 1
Keys stored in app config or shared secrets	Weak separation of duties, poor traceability	Centralize key management and log key access. 1
One-off screenshots as “evidence”	Hard to reproduce; drift goes undetected	Use repeatable exports, policy reports, and versioned documents. 1
Exceptions handled in email/Slack	No governance, no expiry	Use an exception template and register with approvals and review cadence. 1

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the supplied source catalog, so this page does not cite enforcement examples.

Operationally, SC-13 gaps tend to become incident amplifiers: plaintext data paths increase exposure during interception, weak key control increases blast radius after compromise, and missing evidence turns a fixable technical gap into an assessment failure. Treat evidence as part of the control, because assessors grade what they can verify. ¹

Practical execution plan (30/60/90-day)

Use this as an operator sequence. Timelines are illustrative phases; adjust to system complexity and delivery constraints. ¹

First 30 days (stabilize and scope)

• Assign SC-13 owner and publish system boundary statement. ¹
• Draft crypto coverage map for critical systems and top data flows. ²
• Publish cryptographic standard v1 with minimum required configurations and exception process. ¹
• Start an evidence folder structure and define “recurring pulls” (configs, policies, logs). ¹

Next 60 days (enforce defaults and close obvious gaps)

• Enforce TLS at ingress; remove plaintext listeners where possible. ¹
• Validate encryption at rest for primary data stores and object storage; remediate gaps. ¹
• Centralize key management for the highest-risk workloads; restrict key admin roles. ¹
• Stand up exception register with approvals and remediation plans. ¹

By 90 days (audit-ready and repeatable)

• Extend coverage to backups, logs, queues, internal service traffic, and third-party exchanges. ¹
• Add CI/CD checks or policy-as-code to prevent noncompliant crypto configurations. ¹
• Run an internal assessment: pick sample systems and prove compliance end-to-end using only retained artifacts. Fix any evidence gaps. ¹
• In Daydream, map SC-13 to the control owner, implementation procedure, and recurring evidence artifacts so the package stays current between audits. ²

Frequently Asked Questions

Does SC-13 require encryption everywhere?

SC-13 requires you to determine where cryptographic protection is needed, then implement it. Your determination should reflect data sensitivity, exposure, and system design, and you must be able to show how you reached it. ²

What will an auditor ask for first under SC-13?

Expect requests for your crypto standard, proof of encryption in transit and at rest for in-scope systems, and evidence of key management controls. If you cannot show enforcement and repeatable evidence, the control will be graded as weak even if encryption exists in places. ¹

Is “cloud provider encryption by default” enough?

Only if you can show it is enabled for your specific services, that key access is controlled, and that exceptions are governed. Assessors usually want tenant-level evidence (settings, policies, logs), not marketing statements. ¹

How do we handle legacy systems that can’t meet the crypto standard?

Use a formal exception with scope, compensating controls, an expiry, and a tracked remediation plan. Keep the exception register as part of your SC-13 evidence pack. ¹

Do we need to document algorithms and cipher suites?

Document what your organization approves and what is prohibited, then show configurations that implement that decision. Keep the standard readable and enforce it through build/deploy guardrails to prevent drift. ¹

What’s the fastest way to become audit-ready for SC-13?

Write the determination down (coverage map), standardize configurations, and assemble a recurring evidence bundle that you can regenerate on demand. Daydream helps by mapping SC-13 to an owner, procedure, and evidence artifacts so audits stop becoming scramble work. ²

Footnotes

1. NIST SP 800-53 Rev. 5

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