SA-9(7): Organization-controlled Integrity Checking

SA-9(7): organization-controlled integrity checking requirement comes up when your systems place sensitive information into an external system you do not operate, such as SaaS, managed hosting, external databases, third-party analytics platforms, eDiscovery providers, or cloud storage controlled by another entity. The control’s point is narrow: you must be able to check whether information was altered while it sat in that external environment, using a capability you control. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat SA-9(7) as a data-centric control that sits at the boundary between third-party risk management and security engineering. You are not being asked to “secure the vendor.” You are being asked to (1) identify what information is at risk in the external system, (2) implement an integrity verification method that is anchored in your environment (keys, hashes, baselines, or logs you manage), and (3) prove it operates consistently. ¹

This page gives requirement-level implementation guidance you can hand to control owners and assessors, with concrete steps, evidence expectations, and common failure modes.

Regulatory text

Requirement (verbatim): “Provide the capability to check the integrity of information while it resides in the external system.” ¹

What the operator must do:
You must implement a mechanism that lets your organization verify that data stored in a third party’s system has not been modified, corrupted, or tampered with during storage. The mechanism must be under your control (for example, you manage the keys, hashes, signing process, baseline, or authoritative logs), and it must be feasible to run during the period the data remains in the external system. ¹

Plain-English interpretation

If you store your data in someone else’s system, you need a way to independently confirm that the data is still the same data you put there. Do not rely only on the third party telling you “we have integrity controls.” SA-9(7) expects your organization to have a working integrity-check capability, plus records showing it runs and issues get handled. ¹

Who it applies to

Entity scope

• Federal information systems and contractor systems handling federal data commonly inherit SA-9 requirements through system security plans, contracts, or authorization packages aligned to NIST SP 800-53. ²

Operational scope (where SA-9(7) triggers)

• SaaS platforms storing regulated or mission data (case management, HRIS, CRM, ticketing).
• IaaS/PaaS accounts administered by a managed service provider (MSP) or another third party.
• Third-party file transfer, backup, archive, object storage, or content platforms.
• External data processing pipelines where intermediate datasets persist outside your boundary.

Data scope Prioritize datasets where integrity matters operationally or legally: security logs, audit evidence, financial records, incident records, customer records, and authorization artifacts. Document the rationale for what is in-scope and out-of-scope so an assessor can follow your decision. ¹

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

1) Assign ownership and define boundaries

• Control owner: usually Security Engineering or Platform Security; GRC owns oversight and evidence quality.
• System boundary: list each external system where your information “resides,” including the third party name, service, and the storage location type (database, object store, file system, backup vault).
• Integrity objective: define what “integrity” means per dataset (no unauthorized modification, no corruption, no rollback). Keep this specific so engineering can implement tests.

Deliverable: SA-9(7) control statement and RACI mapping SA-9(7) to owners and recurring evidence artifacts. ¹

2) Identify in-scope information and integrity failure modes

For each external system, document:

• Data classes stored (tables, buckets, record types).
• Who can modify/delete the data (your admins, third-party admins, integration accounts).
• Likely integrity risks: unauthorized write, accidental overwrite, vendor-side restore/rollback, sync bugs, malicious insider, compromised API token.

Deliverable: Data residency + integrity risk register entry per external system.

3) Choose an organization-controlled integrity-check method

Pick a method you can operate and evidence. Common patterns:

A. Cryptographic hashes stored in your environment

• Compute hashes for objects/records before upload and store the hash manifest in your controlled system.
• Periodically re-hash data retrieved from the external system and compare to the manifest. Best for: files, exports, backups, artifacts.

B. Digital signatures with organization-held keys

• Sign datasets (or manifests) with keys managed by you; verify signatures on retrieval and on scheduled checks. Best for: packages, evidence bundles, software artifacts, high-assurance workflows.

C. Immutable, organization-controlled audit trail

• Generate append-only logs (or signed logs) from your side when data is written and verify external system state matches expected events. Best for: event-driven systems and integrations where periodic full hashing is expensive.

D. Versioning + integrity validation

• Use external system versioning, but keep independent baselines (hashes or signed manifests) under your control to detect rollback or tampering. Best for: object stores and document systems with version history.

Selection criteria to document:

• What you control (keys, manifests, verification jobs, alerting).
• Check frequency logic (event-based, scheduled, or on-demand for sensitive workflows).
• Coverage: which datasets are checked and what “pass/fail” means.

Deliverable: Integrity-check design record mapped to each external system and dataset. ¹

4) Implement the checks and exception handling

Minimum operational components:

• Job definition: scripts, serverless jobs, CI pipeline, or scheduled workflow that performs verification.
• Alerting: integrity mismatch produces a ticket/alert routed to a named team.
• Triage playbook: what to do when a mismatch occurs (confirm false positives, quarantine, restore from known-good, notify incident response).
• Access controls: restrict who can modify the manifest/baseline and who can disable checks.

Deliverables:

• Runbook (integrity check operations + failure response).
• Ticket workflow mapping severity to response steps.
• Change management note: integrity check code and baseline storage are under standard change control.

5) Bake SA-9(7) into third-party lifecycle controls

SA-9(7) is easier if you handle it at onboarding:

• Contract/security addendum: require APIs or export access needed to perform integrity checks.
• Architecture review gate: no new external system is approved without an integrity-check pattern documented.
• Offboarding: verify integrity of final export and preserve signed/hashes for retention.

Practical note: this is where Daydream fits cleanly. Many teams fail SA-9(7) because they cannot show consistent mapping from external systems to owners, procedures, and recurring evidence. Daydream can track each third party where your data resides, map SA-9(7) ownership, and keep evidence requests and renewals from drifting. ¹

Required evidence and artifacts to retain

Auditors assess SA-9(7) through “show me” evidence. Keep:

1. Control narrative / procedure

• SA-9(7) implementation statement
• Scope (systems + datasets) and rationale
• Roles/responsibilities

2. Technical design evidence

• Architecture diagram showing external system, integrity-check component, and where baselines/hashes live
• Key management description if signing is used (where keys are held and who administers them)

3. Operational evidence (recurring)

• Job configs (scheduler settings, pipeline definitions)
• Sample integrity reports (pass/fail summaries)
• Logs showing executions over time
• Tickets/alerts for failures and closure notes
• Change records for modifications to the integrity-check mechanism

4. Third-party due diligence linkages

• Vendor/third-party onboarding record showing the integrity-check approach is feasible with that service
• Contract or support docs showing you can access the data needed to validate integrity (exports, APIs)

Common exam/audit questions and hangups

Expect assessors to ask:

• “Which external systems store your data, and which datasets are covered by SA-9(7)?”
• “What integrity-check mechanism is under your control?”
• “Show evidence the check ran and how you respond to failures.”
• “Can the third party (or your admins) alter the baseline/hashes without detection?”
• “How do you detect rollback to an older version in the external system?”
• “How do you handle encrypted data where hashing may differ across transformations?”

Hangups that stall audits:

• Control narrative says “vendor provides integrity,” with no organization-controlled verification.
• Checks exist but only run ad hoc; no schedule, no alerting, no ticket trail.
• Hash manifests are stored in the same external system being checked, which weakens independence.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails SA-9(7)	Fix
Relying on third-party SOC reports as “integrity checking”	Attestations do not equal your capability	Keep attestations as supporting evidence, but implement your own verification mechanism. 1
Storing hashes/baselines in the same external system	An attacker who changes the data can change the baseline too	Store baselines in your controlled environment with tight access control and logging.
No defined response to mismatches	Auditors treat this as non-operational control	Write a runbook, route alerts to a named queue, and retain tickets showing closure.
Integrity checks cover only production data, not backups/archives	Tampering often appears in restore events	Include backup exports and archived evidence bundles in scope where relevant.
“We use TLS” as integrity checking	Transport integrity is different from at-rest integrity	Add storage-time verification (hashing/signing/version validation).

Enforcement context and risk implications

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

From a risk perspective, integrity failures in external systems can create:

• Authorization risk: you cannot trust audit logs, evidence, or incident records stored externally.
• Operational risk: corruption or rollback breaks business processes and incident response.
• Third-party concentration risk: a single external system can become a single point of integrity failure across multiple workflows.

A practical 30/60/90-day execution plan

Days 0–30: Establish scope and design

• Inventory external systems where your information resides (start with top critical third parties).
• Define in-scope datasets and integrity objectives per system.
• Select integrity-check patterns per dataset (hashing, signatures, immutable audit trail).
• Draft SA-9(7) control narrative, RACI, and evidence list. ¹

Days 31–60: Build and pilot

• Implement integrity checks for the highest-risk external system first.
• Set alerting to a ticketing queue with ownership.
• Write the mismatch runbook and test a simulated failure.
• Start collecting execution logs and sample reports as audit evidence.

Days 61–90: Expand coverage and harden operations

• Roll out to remaining in-scope external systems.
• Add change control hooks (peer review, approvals for baseline changes).
• Add offboarding/export integrity validation.
• Centralize evidence collection and mapping (many teams use Daydream to keep owners, procedures, and recurring artifacts aligned across third parties). ¹

Frequently Asked Questions

What qualifies as “organization-controlled” integrity checking for SA-9(7)?

You control the verification, not just the third party. Control can mean you manage the signing keys, store the hash baseline in your environment, run the verification jobs, and retain the resulting reports. ¹

Can we satisfy SA-9(7) by reviewing the third party’s SOC 2 report?

A SOC report can support your third-party due diligence, but it does not create your capability to check integrity while the data resides externally. Implement a method you operate and can evidence. ¹

How do we do integrity checking for a SaaS app where we can’t access the underlying storage?

Use what you can control: signed exports, API-based sampling with hash comparison, or event logs generated from your integration layer that can detect unexpected changes. Document limitations and your compensating checks. ¹

Do we need to integrity-check every record in a large database?

The requirement is to provide the capability. Many teams implement risk-based coverage: full checks for critical datasets and sampling or event-based checks for large, lower-risk datasets. Document the rationale and keep evidence the checks run. ¹

What evidence is most persuasive to an assessor?

Execution logs over time, integrity check reports, and tickets showing how mismatches were handled. Pair that with a clear control narrative that maps external systems and datasets to the check method and owner. ¹

Where does this control sit: security engineering or third-party risk management?

Engineering usually builds and runs the checks; third-party risk management ensures contracts, onboarding gates, and evidence retention support the control. GRC should be able to show the mapping across third parties and systems during assessment. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5