SC-36 Distributed processing and storage: requirements

What SC-36 distributed processing and storage asks for when no baseline selects it

If you are a control owner or assessor and SC-36 has turned up in a tailored or overlaid control set, the first thing to know is that SC-36 requires defined processing and storage components to be distributed across multiple physical locations or logical domains, and no SP 800-53B baseline assigns it. It applies only because your organization, or an overlay you adopted, selected it. Until that selection is documented, nobody can say what the control is supposed to achieve in your environment.

The risk it addresses is concentration. If one site, one domain or one storage cluster holds all processing or all copies of critical data, a single compromise, outage or failure can stop or corrupt the whole function. SC-36 asks you to spread those components so that losing one location or domain does not remove the capability. The control carries six organization-defined parameters, which means you choose what is distributed, how many locations or domains are used and what the organization accepts as adequate separation. Release 5.2.0 also adds two enhancements, which address polling (checking whether distributed components are reachable and healthy) and synchronization (keeping their data and state consistent). Both enhancements are optional unless you select them.

The difficulty lies in the definitions. You must decide which components are in scope, where each one runs, and how the copies stay consistent without creating a new shared dependency that undoes the separation. Assessors test this through two determination statements, using the processing site and storage site agreements, facility diagrams and a list of physical locations or environments. Confirm with your assessor which evidence they expect for each defined parameter before you build the architecture, because a design that cannot show its locations and synchronization method on paper will not pass the examine step. The NIST SP 800-53 Rev. 5 publication page and its OSCAL catalog are the places to confirm the exact parameter wording.

Which systems and decisions bring SC-36 into scope

SC-36 applies only when an organization selects it, so the first decision is whether it is in the control set at all. Once it is, the work depends on which processing and storage components are spread across locations or domains, and which providers hold or replicate that data. The cards below cover the decisions that change the assessment.

Selection through tailoring or overlay

SP 800-53B does not place SC-36 in the low, moderate, high or privacy baseline, so it enters the control set only when the organization tailors its baseline or adopts an overlay that names it. Record that selection and the reason for it in the system security and privacy plan. Ask whether an overlay or agency requirement already selects it, because the assessor will test the selection decision as well as the implementation. FedRAMP's Rev5 baselines do not require SC-36 at Class B, C or D, so a FedRAMP system should confirm its own requirements before adding it.

Processing and storage components in scope

The control covers defined processing and storage components, so the first task is to list which ones the organization has defined. Typical candidates are application servers, databases, object storage, message queues and backup repositories. Each component should be tied to a named function and a named location or domain. Components that only hold cached copies or transient data may still need a decision, and the organization should document that decision explicitly.

Physical locations and logical domains

Distribution can mean separate data centers, separate cloud regions, separate availability zones or separate logical enclaves. Assessors examine a list of system physical locations or environments and the system facility diagrams. Confirm which of these boundaries the organization actually uses, because a single cloud account across two zones may not meet the organization's own definition of a separate domain. Keep the location list current when a region or enclave changes.

Third-party hosting and replication services

Managed databases, replication services and backup vendors often decide where data is stored without the platform team making that choice directly. Assessors look for processing site agreements and storage site agreements, which set out where each provider places data. Identify every provider that hosts or replicates a component in scope, and confirm which agreements cover each location. Ask providers which of their regions or sites hold copies, since contract terms may not state it.

Shared design with CP-6, CP-7, PL-8 and SC-32

The related controls CP-6 (alternate storage site), CP-7 (alternate processing site), PL-8 (security and privacy architectures) and SC-32 (system partitioning) usually rest on the same location and domain decisions. A single architecture diagram and one location inventory can often serve all four. Decide these together so that the alternate sites, the architecture and the partitions agree. Splitting them across teams often produces contradictory location records.

Synchronization and recovery responsibilities

Once data is distributed, someone must own how copies stay consistent and how a failed location is recovered. The SC-36 enhancements address polling and synchronization, so the assessor will ask who runs those mechanisms and how their status is seen. Name the owner for each replication path and the monitoring that reports lag or failure. Ownership gaps are a common reason a distributed design passes on paper but cannot be shown to work in practice.

How an assessor tests SC-36 and what they ask to see

This table maps the two SP 800-53A determination statements for SC-36 to the assessment methods, the objects an assessor requests and the findings that commonly come up. Use it to check whether your distributed processing and storage design can be shown with documents and records before the assessor arrives. The assessor sets the sample and depth of testing independently, so treat each row as a minimum set of artifacts to prepare.

Assessment element	What the assessor checks	Evidence to prepare or common finding
Determination statement 1	The organization defines the components of processing and storage to be distributed, and the locations or logical domains they span	Defined parameters in the system security plan; common finding: parameters left undefined or defined only in general terms
Determination statement 2	The defined components are actually distributed across the stated locations or domains, and the distribution is reflected in the system	Current facility diagrams and an inventory of where each component runs; common finding: diagrams that no longer match the running environment
Examine method	The assessor reviews documents and records that describe the distribution	List of system physical locations or environments with distributed processing and storage; system facility diagrams
Examine method (agreements)	The assessor confirms that site agreements exist and cover the processing and storage that actually occur	Processing site agreements and storage site agreements; common finding: agreements that do not cover the stored data or the cloud regions in use
Interview method	Staff explain how distribution is designed, monitored and changed	Named owners for each location or domain; common finding: operators unable to describe failover or data placement
Test method	The assessor observes or tests the distribution in the environment	Live configuration exports, topology views or deployment records showing component placement; the assessor selects what to test
Assessor independence	The assessor independently decides the sample and the depth of testing	Prepare complete, current artifacts for every in-scope location rather than a selected subset

How distributed sites share work and keep data consistent

The two SC-36 enhancements ask the organization to make distributed sites aware of each other and to keep their copies of data in agreement. Polling means components at each site detect or check the state of their peers, for example through health checks, heartbeats or status queries, so a failed or unreachable site is noticed. Synchronization means copies of processing data and stored data converge within a tolerance the organization defines, such as a maximum replication lag or a rule for which copy is authoritative after a split. The control does not set that tolerance. The organization must choose it and write it down.

The organization owns the decisions behind both enhancements. It chooses which physical locations or logical domains hold processing and storage, how far apart they are, and which failures each separation is meant to survive. It also chooses the synchronization design: replication model, polling interval, what counts as divergence, and what happens when sites disagree. Confirm with each platform vendor exactly how its replication, leader election and state checks behave, because a self-hosted database or storage cluster may offer a different set of options than a general-purpose design assumes. An implementation partner can build and test that design, but the organization must approve it and accept the residual risk.

SP 800-53A checks whether this design is documented and operating, not whether it looks sound on a whiteboard. Assessors examine the list of system locations or environments that distribute processing and storage, system facility diagrams, and the processing and storage site agreements. They also interview operators and test that a peer failure is detected and that copies return to agreement within the defined tolerance. Evidence that tends to satisfy this includes current diagrams, signed site agreements, polling and lag metrics kept over time, and alert records. A self-hosted stack such as Prometheus can collect peer health and lag metrics, and Grafana alert rules can show when a tolerance is breached. Periodic integrity checks of replicated backups, such as restic's read-data checks, can confirm that stored copies are unmodified.

How to implement SC-36 in an existing environment

The sequence turns SC-36 from a distributed architecture idea into a documented, testable set of parameters, mapped systems, closed gaps and agreements that an assessor can examine.

Define the organization-defined parameters
Start by deciding, in writing, which processing and storage components SC-36 covers, which physical locations or logical domains they must span, and what polling and synchronization behavior the enhancements require. The system owner and the security lead approve these values, because SC-36 has six organization-defined parameters in Release 5.2.0 and each one has to be filled in before anything else can be tested. The output is a signed parameter record that names every component in scope, the locations or domains for each, and the synchronization expectations. The step is done when no parameter is left blank or described only as "appropriate."
Inventory the current architecture against the parameters
Map the existing environment to the parameter record. Architecture, infrastructure and platform engineers list where each in-scope component runs, which site or domain holds each copy of processing and storage, how data is replicated, and how failover is triggered. Diagram the real topology, including cloud regions, data centers, clusters and backup targets, rather than the intended design. The output is a current-state inventory with a location and domain column for every in-scope component. The step closes when every component in the parameter record appears in the inventory and every mismatch is noted.
Identify single points of compromise or failure
Compare the inventory with the parameters and find where processing or storage depends on one location, one administrative domain or one identity source. Typical findings include a single storage cluster behind a shared credential, a backup repository in the same failure domain as production, or a synchronization job that cannot continue when one site is unreachable. Record each finding with its affected components, its impact and an owner. The output is a gap register that an assessor can trace back to the SC-36 determination statements. The step closes when every gap has an owner and a planned disposition, even if the disposition is to accept the risk through the organization's normal process.
Close replication and failover gaps
Engineers change the design where the gap register requires it. This can mean adding a second storage location, separating administrative access for each domain, configuring replication between sites, or setting how polling and synchronization detect a lost site and recover. Open-source backup and monitoring tools can support this work. For example, Bareos schedules backup, restore and verify jobs and keeps a catalog of backed-up files, and Prometheus collects metrics from instrumented jobs over HTTP, which helps show whether synchronization is running. Confirm each tool's capabilities against your own design before relying on them. The output is a change record per gap with a test result showing the change works. The step closes when each change has been tested in a non-production environment and the test is documented.
Document the site and storage agreements
Collect or write the agreements that govern each location used for processing and storage. These include processing site agreements and storage site agreements, which the SP 800-53A examine methods ask for. Legal, procurement and the system owner review terms covering data location, access rights, recovery responsibilities, notification and exit. Where a third-party provider hosts a site, confirm who signs and who holds the agreement. The output is a signed agreement set indexed to each location in the inventory. The step closes when every location in the inventory has a current agreement on file and no location depends on an unwritten arrangement.
Produce diagrams and configuration records
Prepare the artifacts an assessor will request. These are system facility diagrams showing the physical locations and logical domains, the current-state inventory, configuration exports for replication, failover and synchronization settings, and the monitoring rules that alert when a site or sync job fails. Keep the diagrams aligned to the inventory, dated and version controlled. The output is a documented evidence package that names each artifact and the component it covers. The step closes when an engineer outside the project can locate each artifact from the parameter record without help.
Test the distribution and record the results
Run planned tests that show processing and storage keep working when one location or domain is unavailable, and that synchronization recovers when service returns. Use restore and integrity checks where relevant. For example, restic can verify the structural consistency of its repository and, with read-data options, confirm that stored pack files are unmodified. Record the test scope, date, outcome and any deviation. The output is a test log linked to the parameters and gap register. The step closes when each parameter has at least one recorded test result or a documented reason why a test is not feasible, and the owner accepts that position.
Hand the package to the independent assessor
Assemble the parameter record, inventory, gap register, agreements, diagrams, configuration records and test log into one package for the organization's assessment team. The implementation partner can prepare this material, but the organization owns the control and the independent assessor performs the assessment and issues any report. Confirm which artifacts the assessor requested, answer questions with the people who run the systems, and track any findings back into the gap register. The step closes when the assessor has examined the package and every finding has a recorded response.

Evidence that passes an SC-36 assessment

SC-36 is assessed largely by examining documents that show where processing and storage live and how they stay in step. The cards below cover the examine objects in SP 800-53A and the supporting records an assessor will ask for, along with the change control that keeps each one current between assessments.

Current list of physical locations

This is the inventory of every physical location or logical environment that hosts distributed processing or storage for the system. It is the first examine object SP 800-53A names for SC-36, so it must match what is actually running. Check that each entry names the site, the components hosted there, the domain or cloud account and the owner. Reconcile it against the asset inventory and the cloud account list every quarter, and tie any new site to a change request before data is placed there.

Facility and architecture diagrams

Diagrams show how processing and storage nodes connect, where replicas sit and which paths carry data between them. Assessors use them to confirm that the distribution described in the plan is the one that exists. Each diagram should carry a version number, date and owner, and should show failure domains such as availability zones, data centers or enclaves. Regenerate the diagrams from infrastructure-as-code where possible, and require an updated diagram in every change that adds or moves a site.

Processing and storage site agreements

The examine objects include processing site agreements and storage site agreements, which record the obligations between the organization and each site operator or hosting provider. Confirm that each agreement names the locations covered, security and availability responsibilities, incident notification duties and the conditions for moving workloads. Ask legal and procurement to keep these in the same repository as the contract register, and to flag expiring agreements well before renewal so a site cannot quietly fall out of scope.

Parameter definitions in the security plan

SC-36 has organization-defined parameters, and an assessor will look for their values in the system security and privacy plan. The values should state which components are distributed, the number and type of locations or domains, and the polling or synchronization intervals selected. Vague wording such as "multiple sites" will not pass review. Record each value with its rationale, and update the plan through the same change process used for other control parameters, with a date and approver on every revision.

Synchronization and polling configuration exports

Configuration exports show the settings that actually drive replication, polling and synchronization, such as replication targets, intervals, quorum rules and failover order. Export them from the running system rather than copying them from design documents, and store each export with a timestamp. Compare exports between releases to catch silent drift. Where an enhancement on polling or synchronization is selected, the export is the evidence that it operates as described, so keep it with the configuration baseline.

Takeover and convergence test records

Test records show that a site can take over processing when another fails and that stored data converges across locations after synchronization. Keep the test plan, the scenario, the start and end times, the observed results, and any defects with their remediation dates. Backup verification output from tools such as restic or Bareos can support convergence claims, but the record must show the site-level result. Repeat these tests after material changes, and schedule them so each assessment has recent results to examine.

Keeping evidence current through change control

Every artifact above goes stale when a site, route or parameter changes, so each one should be linked to the change management process. Require that a change adding, moving or retiring a location updates the location list, diagrams, agreements and plan parameters before the change is closed. Review the full set on a fixed schedule and record the review. Ask an independent assessor which evidence they will request first so the review focuses on the artifacts they examine.

Open-source tools that produce SC-36 evidence

No single open-source tool satisfies SC-36, and the organization still has to decide which processing and storage components are distributed, across which physical locations or logical domains, and what the defined parameters are. The tools below can produce supporting records for the decisions and the operating state, but the assessor will still expect the organization's own design documents, site agreements and rationale. Treat each tool as a source of evidence for one part of the control, not as the control itself.

Bareos is the strongest candidate for storage distribution evidence. Its Director schedules and supervises backup, restore, verify and archive jobs and keeps a SQL catalog of backed-up files, so the catalog can show which storage targets hold backup data at each site and let you demonstrate restores from the current backup or one taken before a given date and time. Confirm that your chosen storage daemons and retention settings match the site list in your design documents. Also check the license: Bareos is AGPL-3.0-only, so if you modify and redistribute it, or offer it to others over a network, you need to review the source-disclosure obligations with counsel before you build the service around it.

restic (BSD-2-Clause) supports the storage side with integrity evidence. Running restic check verifies the structural consistency of snapshots, trees and pack files, and adding --read-data or --read-data-subset reads pack files back to confirm the stored data is unmodified. Grafana Alerting (AGPL-3.0-only) and Prometheus (Apache-2.0) cover the polling and monitoring side. Prometheus pulls metrics over HTTP into time series that you can query with PromQL, which can record site availability and synchronization health over time. Grafana builds alert rules across multiple data sources and alerts on metrics and logs together, which can show that each site is covered. Confirm the alert thresholds and synchronization intervals with your own risk owners, since the tools do not set them.

What meeting SC-36 costs in money and effort

This table compares the cost components of putting SC-36 in place, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to structure a written quote and to see where open-source tooling may reduce license spend, while noting that no figures are stated here because none are supplied for this control.

Cost component	One-time or recurring, and who is paid	What drives it up or down	What to ask for in a quote
Architecture review and parameter definition	One-time engineering time, paid to internal architects or the implementation partner	Number of defined processing and storage components, and how many of the six organization-defined parameters must be set	Named deliverables for the parameter decisions and the site and domain diagram
Added infrastructure for a second site or domain	One-time build plus recurring hosting, bandwidth and licenses, paid to cloud or data center providers and software vendors	Number of sites, data volume, and whether existing replication or a second cloud region already exists	Itemized hardware, hosting and bandwidth assumptions, and which licenses are replaced by open-source tools
Site and storage agreements	One-time legal and procurement time, paid to internal counsel, procurement or outside counsel	Number of counterparties, whether agreements already exist for alternate sites, and jurisdictional requirements	Whether drafting and review of processing and storage site agreements is in scope and who signs off
Synchronization and polling build	One-time engineering time, paid to internal engineers or the implementation partner	Replication design, consistency needs, and the number of components that must stay synchronized	Description of the synchronization method, failure handling and test plan for the polling enhancement
Evidence upkeep	Recurring staff time for diagrams, agreements and metrics, paid internally or under a support retainer	Frequency of architecture change, number of sites, and whether monitoring tools already collect the needed data	Retainer scope covering evidence refresh cadence and who maintains the location inventory
External testing or review	Fixed-scope fee paid to an independent reviewer or testing firm, not the auditor	Depth of the architecture review and whether failover or distribution is tested in practice	Written scope, deliverables and timeline agreed before work starts
Auditor sampling	Set by the independent auditor, paid by the organization	Sample sizes the auditor selects, number of locations to examine, and quality of prepared evidence	Auditor's written sampling approach and the evidence list it expects before fieldwork

Who owns SC-36 work, who can help and where the auditor stops

The organization owns SC-36 from start to finish. It decides whether the control is selected at all, since SP 800-53B does not place SC-36 in any baseline and it applies only through tailoring or an overlay. It also defines the organization-defined parameters, identifies which processing and storage components must be distributed, names the physical locations or logical domains involved, and signs the agreements that assessors will examine. The residual risk that remains after distribution is an accountable business decision, not a technical task.

Selection and tailoring: Record whether SC-36 is selected, the reason, and the overlay or tailoring decision behind it.
Parameter values: Set the six organization-defined parameters, including which components are distributed and across which locations or domains.
Site and processing agreements: Hold the processing site and storage site agreements that the assessment examines.
Risk acceptance: Decide which single points of compromise or failure remain acceptable, and document who approved that decision.
Ownership of evidence: Keep the facility diagrams and location lists current after each architecture change.

Before any engagement starts, confirm internally who signs the risk decision and who maintains the location inventory after the project closes.

Where SC-36 implementations usually fall short

SC-36 is simple to state and easy to claim, which is why assessments of it often turn on documents rather than systems. The gaps below recur because the parameters, diagrams, agreements and failover tests that prove distribution are maintained separately, and each one can drift from the environment it describes.

Parameters never defined

SC-36 has 6 organization-defined parameters in Release 5.2.0, and an assessor cannot test distribution until the organization sets them. Typical gaps are an undefined list of components to distribute, no stated minimum number of locations or domains, and no statement of which storage counts as covered. Close this with a signed parameter table that names each component, the locations or domains it spans, and the owner who approves changes. Ask the assessor to confirm the parameters match the test they will run.

Diagrams that drift

Facility and network diagrams are often drawn at deployment and then left unchanged while workloads move, replicas are added and storage tiers are reassigned. An examiner who compares a diagram with the running environment will find the gap quickly. Close this with diagrams generated from configuration or inventory data, dated and tied to a change record, and a periodic reconciliation that compares the diagram with live locations. Record every mismatch and its resolution.

Site agreements that skip the data

Processing site and storage site agreements frequently describe the facility, its service levels and its physical security, but never name the data classes, systems or workloads that will reside there. That leaves the assessor unable to confirm that the stored information is the information the control was meant to protect. Close this by adding an annex to each agreement that lists the systems, data categories and replication scope, and by checking that the annex matches the parameter table. Confirm with counsel whether existing contracts need amendment.

Untested secondary sites

A second site that receives replicated data but has never run as a working environment does not show that processing can continue if the primary is lost. Teams often confirm that backups exist and assume takeover will work. Close this with a documented takeover test that starts workloads at the secondary site from current replicated data, measures what was restored and records the results. Keep the test record with the contingency plan evidence so the two controls can be reviewed together.

Synchronization without monitoring

Replication between sites is often configured once and never observed, so lag, failed jobs and divergent copies go unnoticed until a failover or audit exposes them. A configured sync job is not evidence that copies agree. Close this by alerting on replication lag, failed syncs and checksum or verification mismatches, and by keeping the alert history. Self-hosted tools such as Prometheus can collect the lag metrics and Grafana Alerting can route the notifications, and restic's check command with --read-data can verify backup content read back from a repository.

Cloud regions as separate domains

Organizations sometimes count two cloud regions or availability zones as independent domains without evidence that they fail independently. Shared identity providers, control planes, DNS or a single account can make both regions fall together. Close this by documenting the shared dependencies for each region, testing or reviewing the provider's failure isolation claims, and recording which services remain common. Confirm the provider's documented regional and zonal boundaries before the diagram names them as separate domains.

Questions buyers ask about SC-36 cost, time and effort

Is SC-36 required if my system has no baseline assigned?

No. SP 800-53B does not assign SC-36 to the low, moderate, high or privacy baseline, so it applies only when your organization selects it through tailoring or an overlay. Appendix C of SP 800-53 Rev. 5 lists SC-36 as implemented by the organization and marks it as an assurance-related control. The practical question is therefore whether your risk assessment, your authorizing official, or a contract or overlay that governs your system asks for it. Start by reading the tailoring decision in your system security plan. If SC-36 is not selected there, the work described on this page is not a requirement for that system. If it is selected, the parameters you define for it set the scope of the effort.

What drives the cost of distributing processing and storage?

Cost follows the number of locations or logical domains you define, how many components must be distributed, and how much replication already exists. Release 5.2.0 gives SC-36 six organization-defined parameters, so the scope is largely set by your own decisions about what is distributed and where. Expect one-time costs for architecture design, site or domain provisioning, data replication setup, failover testing and documentation. Recurring costs include the infrastructure for each additional location, bandwidth between sites, monitoring, backup verification and the staff time to keep site agreements and diagrams current. Ask any implementation partner for a quote that separates design, build, testing and evidence preparation, and that states which of your own staff hours are assumed.

Can we implement SC-36 in-house without an outside partner?

Yes, if your team has the skills to design and operate multi-site or multi-domain architecture, and the capacity to produce the evidence an assessor will examine. The control itself does not require a partner. Your team owns the control and remains accountable for its operation. An implementation partner can prepare the systems, configure replication and backup, and assemble evidence such as facility diagrams and site agreements. Only an independent assessor or auditor can issue an assessment result. Decide in-house versus external by comparing your staff's experience with distributed systems, their availability during the build, and whether they have done a control assessment against SP 800-53A before.

How long does SC-36 take, and what does it need from our team?

The timeline depends mainly on the number of sites or domains, how much replication and failover already exists, and how many of your existing systems must be brought into the distributed design. Organizations with mature replication often need less time than those starting from a single site. No supplied figure gives a duration for this control, so ask any partner for a timeline built from the written scope rather than a generic estimate. Your team will need to supply facility information, network and cloud account access, decisions on which components must be distributed, sign-off on processing and storage site agreements, and time for testing. DeployOpen scopes engagements in writing before work starts, so the agreed deliverables and schedule are fixed in that document.

Do open-source tools remove the need for licenses?

Open-source tools remove license fees for the software itself, but licensing terms still apply and must be checked. Bareos is licensed under AGPL-3.0-only, restic under BSD-2-Clause, Grafana under AGPL-3.0-only and Prometheus under Apache-2.0. Each license has different obligations, particularly for the AGPL when software is modified and offered over a network. Your legal team should review how each component will be used. You will still pay for infrastructure, hosting, storage, staff time and any support contract you choose. Confirm the license terms of each component against the project's own published license file before you adopt it.

Who issues the assessment result for SC-36?

Only an independent assessor or auditor issues the assessment result. NIST's SP 800-53A gives the assessment procedure for SC-36 through two determination statements, using examine, interview and test methods. The examine objects include the list of system physical locations or environments with distributed processing and storage, system facility diagrams, processing site agreements and storage site agreements. An assessor checks those artifacts and tests the configuration. DeployOpen prepares systems, controls and evidence for an assessment, but does not issue audit reports, attestations or certifications. Organizations that require an independent view should confirm the assessor's qualifications and authority with the body that set the requirement.

What evidence do we need to show an assessor for SC-36?

Prepare the documents and records that correspond to the examine objects in SP 800-53A. These include a current list of physical locations or logical domains where processing and storage are distributed, system facility diagrams that show those locations, processing site agreements and storage site agreements. Add configuration records for replication and backup jobs, and results from failover or restore tests. Open-source tools can generate some of this evidence. Bareos keeps a SQL catalog of backed-up files and restores from earlier points in time, restic check can confirm backup data is unmodified, and Prometheus and Grafana can record and alert on the health of distributed components. Confirm with your assessor which artifacts they will accept in your environment before you build the evidence set.

How DeployOpen scopes and prepares SC-36 evidence

DeployOpen approaches SC-36 Distributed processing and storage as a scoped engagement inside your own infrastructure. We agree in writing which processing and storage components are distributed, what evidence will be prepared, and what remains for your organization and your independent assessor to decide and verify.

How we scope

Confirm whether SC-36 is selected in your tailored baseline or overlay, since no SP 800-53B baseline includes it.
List the processing and storage components in scope and the locations or logical domains they span.
Agree the written scope, deliverables and timeline before any work starts, as all engagements are fixed-scope.

How we build

Configure distributed storage and processing across the locations or domains you define in your own cloud accounts or data centers.
Document site agreements and facility diagrams that show where each component runs and how it is separated.
Test failover and synchronization between sites and record the results for review against the assessment procedure.

How we hand over

Deliver the architecture records, configuration exports and test results that map to the SC-36 determination statements.
Walk your team through the evidence so your own staff can explain and maintain each distributed component.
Note open items and residual gaps in writing so your organization decides how to track them in its plan of action and milestones.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Review changes to site layout, storage replication or related controls such as CP-6, CP-7, PL-8 and SC-32.
Refresh evidence when your environment changes so that your independent assessor reviews current material.