What are the NIST 800-53 control families and how do they fit together?
If a contract, agency or FedRAMP requirement names NIST SP 800-53, the first thing to understand is its structure. SP 800-53 Rev. 5 has 20 control families. The first ten run from Access Control (AC) through Media Protection (MP), and the second ten run from Physical and Environmental Protection (PE) through Supply Chain Risk Management (SR). The families group controls by purpose: access and identity, logging and monitoring, configuration and maintenance, recovery, incident response, planning and governance, and the newer privacy and supply chain families.
Nineteen of the 20 families open with a -1 control for policy and procedures, such as AC-1 or IA-1, which requires the organization to set out its policy and the procedures that carry it out for that family. Program Management (PM) is the exception, because its first control, PM-1, sets up the organization-wide information security program plan instead. Treat the -1 controls as the governance layer that the rest of each family depends on, and confirm that your policy owners can show current versions for every family in scope.
The families are not a checklist. SP 800-53B selects controls from them into the low, moderate and high baselines and the privacy baseline, and an organization may tailor those selections. In Release 5.2.0 the catalog holds 324 base controls and 872 control enhancements, of which 1,014 items are active, so the family structure is the map for a much larger set than any single baseline. The organization owns its controls and decides how they are implemented. DeployOpen can help plan, implement and document them in your environment, but only an independent assessor issues any assessment report, and DeployOpen does not do that.
Which control families cover access, operations and governance?
The 20 families of SP 800-53 Rev. 5 group naturally by the question each one answers: who can get in, how activity is recorded and changed, how the system recovers, who handles people and places, how the program is governed, and what is bought from others. Use these groupings to map ownership and find which families your team, your contractors and your inherited common controls must each cover.
Identity and access
AC, IA and MP decide who may reach a system, prove who they are, and control how media holding data is handled. AC covers account management, least privilege, session and remote access. IA covers users, devices, services and identifier and authenticator management. MP covers storage, transport and sanitization of media. Check that account lifecycle records and authenticator settings can be exported as evidence without manual screenshots.
Logging and monitoring
AU, SI and RA turn system activity into records and findings. AU defines which events are logged, what each record contains, how long it is kept and how it is reviewed. SI covers monitoring, malicious code protection and flaw remediation. RA covers vulnerability scanning and risk response. Confirm that logs from every in-scope component reach a store the operations team cannot silently alter.
Change and configuration
CM, MA and SA govern how systems are built, altered and maintained. CM sets baseline configurations, change control and component inventory. MA covers maintenance tools, personnel and nonlocal maintenance sessions. SA covers the system development life cycle, developer testing and unsupported components. Check that every change ticket links to an approved baseline and that the inventory matches what is actually running.
Resilience and incident response
CP and IR determine whether the organization can keep running and recover after a failure or attack. CP covers contingency plans, alternate sites, backup and reconstitution, and testing of those plans. IR covers incident response policy, handling, reporting and the incident response plan. Ask whether restore tests and tabletop exercises produce dated records that an assessor can examine.
People, facilities and communications
PE, PS, AT and SC cover the physical, human and network boundary around the system. PE covers facility access, visitor records and environmental protection. PS covers screening, termination, transfer and sanctions. AT covers role-based training and training records. SC covers boundary protection, encryption, key management and time synchronization. Confirm which of these are inherited from a hosting provider and which remain your responsibility.
Governance, privacy and supply chain
PL, PM, CA, PT and SR set the program rules and oversight. PL and PM define security plans and organization-wide program controls. CA covers control assessments, plans of action and milestones, and authorization. PT covers PII processing authority and privacy notices, and sits in the privacy baseline. SR, new in Rev. 5, covers the supply chain risk plan, supplier assessments and component provenance. Check that PM-1 and PL-2 are written before system-level procedures are finalized.
Why does the -1 policy and procedures control open almost every family?
Nineteen of the twenty SP 800-53 Rev. 5 families begin with a -1 Policy and Procedures control, such as AC-1, AU-1 or SI-1. The exception is Program Management, which opens with PM-1 Information Security Program Plan instead. The -1 control asks the organization to develop, document and disseminate a policy for the family's subject area and the procedures that carry it out, to review and update both at a defined frequency, and to assign an owner for them. In practice, each family's -1 control is the written foundation that the other controls in that family point back to. A control such as AU-2 on event logging assumes that someone has defined the policy and procedures behind it, so the -1 control is where an assessor starts.
Assessors test the -1 controls early because they show whether the rest of a family has an authorized source of truth. A missing or outdated procedure document usually means that the operational controls in that family cannot be shown to be governed. Confirm, for each family in scope, that the policy names an accountable owner, that the procedures describe how the work is actually performed in your environment, that both were reviewed within the frequency you set, and that staff who need them can find them. Release 5.2.0 updated the -1 controls as part of its software update and patch security changes, so a program that last reviewed its policies before that release should check whether its patch and update procedures now need revision.
To see the control text, use the CPRT entry for PT-01 Policy and Procedures in SP 800-53 Release 5.2.0, which is the same structure every -1 control follows. Note that CPRT writes identifiers with a leading zero (PT-01 rather than PT-1). Use the official NIST text, including the parameter values and the current release, when you draft your own policies, and treat any summary, including this one, as a guide to what to check rather than a substitute for the control wording.
Which controls does the organization implement and which does the system implement?
Controls labeled O are implemented by the organization as a whole, through policy, governance, people and processes, rather than by a configuration on a single system. Appendix C records this label for each control and enhancement, so a reader can see at a glance which obligations sit with the enterprise. Many of the policy and procedures controls, the training controls and much of the Program Management family fall here. Because these controls apply across systems, one owner usually writes the artifact and every system in scope points to it.
- Typical examples: organization-wide policies, the information security program plan, role-based training programs and personnel screening standards.
- Who writes the evidence: the function that owns the policy, such as the CISO office, HR or privacy, not the system administrator.
- Who an assessor interviews: the executives and process owners who approve and enforce the policy, in addition to system staff.
- Reuse: a single approved policy can support many system authorizations, so it should be versioned once and referenced in each system security and privacy plan.
- Scope creep risk: teams sometimes write system-specific copies of organization policies, which then drift apart.
Confirm with your assessor which O controls must be shown per system and which can be evidenced once at the enterprise level.
Controls labeled S are implemented by the information system itself, usually through technical configuration, software behavior or the hosting environment. Examples include access enforcement, audit record generation, encryption of data at rest and session timeouts. Evidence for these controls is produced by the system and must be specific to the boundary being assessed, because a generic statement that a control exists does not show that it operates on that system.
- Typical examples: account lockout settings, audit logs on application servers, boundary protection rules and malware scanning on endpoints.
- Who writes the evidence: the platform or operations team that configures the system, with screenshots, configuration exports and log samples.
- Who an assessor interviews: system administrators, engineers and the people who run the monitoring pipeline.
- Traceability: each S control should name the component that enforces it, such as a specific service, host group or infrastructure module.
- Drift: configuration changes after the assessment can silently break an S control, so evidence should be regenerated on a schedule.
Check that each S control in your plan names the component and the configuration baseline that implements it, not only the policy behind it.
Controls labeled O/S need work from both sides. The organization defines the requirement, such as a rule for how often accounts are reviewed or who may approve a change, and the system carries out the mechanics that prove it happens. These are often the hardest controls to evidence because a gap can sit between the two owners, with the policy written and the configuration missing, or the reverse.
- Typical examples: account review, configuration change control, vulnerability scanning cadence and incident handling.
- Split of work: the organization sets the policy and approval workflow, while the system generates the tickets, logs and scan results that show the workflow ran.
- Who writes the evidence: both parties, with a clear note in the plan on which part each one produces.
- Who an assessor interviews: the process owner and the operator, and the assessor will often compare the two to confirm they describe the same process.
- Common gap: a policy requires a review frequency that the tooling does not record, so no evidence can be produced.
For each O/S control, verify that the policy and the system evidence agree on frequency, owner and scope.
A common control is one implemented once and inherited by multiple systems. Inheritance changes who owns the evidence and who answers for it during assessment. A system that inherits a control depends on the provider's implementation, and the provider's assessment results become part of the inheriting system's authorization package. Under this model, the organization or a provider such as a hosting platform owns the control, and the consuming system documents how it relies on that control.
- Provider responsibility: the common control provider keeps the evidence current and shares it with each consumer.
- Consumer responsibility: each system documents which inherited controls it relies on and what it still implements locally.
- Shared responsibility: a control can be partly inherited and partly local, which should be recorded explicitly.
- Assessment impact: an assessor reviews the provider's results and checks that the consumer's use of them matches the agreement.
- Change impact: if a provider changes a control, every consumer may need an update.
Confirm that every inherited control in your plan names its provider, the date of the provider's latest evidence and the agreement that governs it.
The O, S and O/S labels in Appendix C are a starting point. Each organization must decide, for each control in its system boundary, who implements it, what evidence proves it and whether it is inherited, and then record those decisions. In practice, the system security and privacy plan is where this record lives, because it describes how each control is implemented for the specific system. A label copied from the catalog without this analysis does not show who is responsible.
- Start from the label: use Appendix C as the default, then adjust for your architecture, hosting model and contracts.
- Record the implementer: name the team, service or provider for each control.
- Record inheritance: identify the common control, its provider and the consumer obligations.
- Record the evidence: name the artifact, its location and how often it is refreshed.
- Review changes: update the split when architecture, providers or responsibilities change.
Ask your assessor to confirm that the split in the plan matches the assessment scope before testing begins.
What does each of the 20 control families cover?
What do the access control and identification and authentication families cover?
AC and IA decide who can reach a system and how the system confirms that a user, device or service is who it claims to be. AC covers account management, least privilege, session controls, access enforcement, and remote, wireless and mobile access, including the rules for using external systems. IA covers how users, devices and services are authenticated, including multifactor authentication, identifier and authenticator management and identity proofing. Assessors usually ask for the account inventory, approval records for privileged access, a sample of access reviews with the removals they produced, authentication settings exported from the identity provider, and session logs showing granted and denied access. Evidence exported from the system itself carries more weight than a spreadsheet written for the audit. Ask your partner which identity settings and access review exports they will capture as recurring evidence.
What do the audit logging and system integrity families require in practice?
AU and SI cover the records a system keeps and the protections that keep its code, data and alerts trustworthy. AU covers which events are logged, what each record contains, how logs are stored and protected, how logging failures are handled, how logs are reviewed, how clocks are synchronized and how long records are retained. SI covers flaw remediation, malicious code protection, system monitoring, security alerts, integrity verification and input validation. Assessors typically look for a documented list of auditable events, sample log records showing the required fields, evidence that logs are forwarded to a protected store, review records with follow-up tickets, and remediation records with actual closure dates. A common gap is logging that is configured but never reviewed, so the review record matters as much as the logging configuration.
How do configuration management and maintenance controls get tested?
CM and MA govern how a system is built, changed and serviced so that production matches what was approved. CM covers baseline configurations, change control and impact analysis, component inventories, least functionality, software restrictions and signed components. MA covers the maintenance policy, controlled maintenance performed locally and remotely, the tools and personnel used for maintenance, and timely repair. Assessors usually request a current baseline configuration, a sample of change tickets showing approval and testing before deployment, an inventory reconciled against scanner results, and maintenance logs for remote sessions that record who approved each session. Infrastructure as code repositories, configuration scanners and pipeline logs can produce much of this evidence automatically, but change approval decisions still need signed human records.
What must backup, recovery and media handling evidence show to an assessor?
CP and MP cover whether a system keeps running and recovers after disruption, and how data on physical or digital media is protected through its life. CP covers the contingency plan, staff training and exercises, alternate storage and processing sites, telecommunications, system backup, and recovery and reconstitution. MP covers media access, marking, storage, transport, sanitization before reuse or disposal, and the use of removable media. Assessors commonly look for the approved contingency plan, exercise reports with lessons learned, backup job logs, and restore test results showing the system returned within the recovery objectives the organization set. For media, they want sanitization records tied to asset identifiers and chain-of-custody forms for transport. Recovery objectives are set by your organization, so confirm them with the system owner before any test runs.
How do the assessment, planning and program management families fit together?
CA, PL and PM hold the program together: they describe the system, the organization-wide program behind it, and how the authorization is assessed and kept current. CA covers control assessments, information exchange agreements, plans of action and milestones, authorization, continuous monitoring and penetration testing. PL covers the security and privacy plans, rules of behavior, concept of operations, architecture and baseline selection and tailoring. PM covers organization-wide program controls such as the information security program plan, risk management strategy, and supply chain and workforce program elements, which are deployed at the program level across the organization. Assessors look for a current system security plan that matches the running system, a signed assessment report, dated plan of action and milestones entries, and an approved program plan. Mismatches between the documented plan and the live environment are among the most common findings.
What do training, personnel security and physical protection controls require?
AT, PS and PE cover the people who operate a system and the facilities where it runs. AT covers security and privacy literacy training, role-based training for people with specific duties, training records and feedback on training results. PS covers position risk designation, screening, termination and transfer steps, access agreements, sanctions for violations and requirements for external personnel. PE covers physical access authorization, monitoring, visitor records and environmental safeguards such as power, fire and water protection. Assessors usually request training completion records by role, sample personnel files showing screening and signed access agreements, termination checklists with timestamps, and visitor logs or badge reports for the facility. Where a cloud provider hosts the system, physical controls are often inherited, so your evidence focuses on the provider's documentation and your own access to the environment.
What do risk assessment, acquisition and supply chain families expect from teams?
RA, SA and SR address the risks that come from how a system is categorized, acquired, built and supplied. RA covers security categorization, risk assessments, vulnerability scanning and monitoring, risk response, privacy impact assessments and threat hunting. SA covers the system development life cycle, acquisition contract requirements, external services, developer testing, secure development practices and the handling of unsupported components. SR is the family added in Revision 5 and covers the supply chain risk management plan, provenance, supplier assessments, notification agreements, tamper protection, component authenticity and disposal. Assessors commonly ask for the categorization record, a current risk register with treatment decisions, scan reports with remediation tickets, contract clauses covering security and notification, and a supplier inventory listing the assessments performed on each supplier.
Which evidence proves encryption, incident response and privacy controls work?
SC, IR and PT cover how data moves and is protected, how incidents are handled, and how personal information is processed. SC covers boundary protection, encryption in transit and at rest, key and certificate management, DNS and session security, isolation and time synchronization. IR covers incident response policy, training, testing, handling, monitoring, reporting and the response plan. PT covers the authority and purposes for processing personal information, consent, privacy notices and related transparency duties, and it sits in the privacy baseline, separate from the security baselines. Assessors typically ask for encryption configuration scans, key inventory and rotation records, a tabletop exercise report with action items, incident tickets with timelines, and privacy notices tied to documented processing purposes. Confirm with counsel which privacy obligations apply to your processing.
Where do privacy and supply chain controls sit in SP 800-53?
The PII Processing and Transparency (PT) family is not allocated to the low, moderate or high security control baselines. Instead, PT-1 sits in the privacy baseline, which SP 800-53B applies to systems regardless of impact level. An organization that handles personally identifiable information must therefore check the privacy baseline even if its system is categorized as low impact for confidentiality, integrity and availability. The practical first step is to confirm, with your privacy office, which systems process PII and which PT controls the privacy baseline selects for each of them. Do not assume that a clean security categorization removes privacy obligations.
The Program Management (PM) family works at a different level. Its controls cover organization-wide security, privacy, risk and supply chain program functions, such as the information security program plan in PM-1, and they are deployed across the organization rather than inside each system boundary. Because of this, a PM control is usually implemented once and inherited by many systems. Supply Chain Risk Management (SR) is also new in Rev. 5. It was separated out so that supply chain requirements could be selected independently of the security baselines. SR coverage is therefore not automatic for any system. You must select and tailor it through SP 800-53B and document the decision, including which SR controls apply to your suppliers, components and acquisitions.
Neither PT nor SR appears by default in the baselines a system inherits from its impact level, so the organization decides which of them apply. Record that decision in the system security and privacy plan with a short rationale for each selected or excluded control. Confirm the decision with your authorizing official or assessor before assessment begins, because a tailoring choice that is undocumented is the most common reason an SR or PT gap surfaces late. An outside partner can help map systems to privacy obligations and draft the SR plan, but the selection and the risk acceptance stay with your organization.
How do you turn the 20 families into a control set for your system?
The sequence starts with what the system is worth to the mission and ends with a control set that an independent assessor can test against SP 800-53A, with each step leaving a written record that the next step depends on.
Categorize the system by impact
The system owner, with the information owner and security staff, assigns a security impact level for confidentiality, integrity and availability, using the FIPS 199 approach that NIST's Risk Management Framework relies on. The highest of the three values becomes the system's overall impact level, which determines which SP 800-53B security baseline applies. The output is a signed categorization record that names the information types, the impact levels and the reasons for each rating. The step is done when the authorizing official or the system owner accepts that record in writing.
Select the baseline from SP 800-53B
Using the categorization, the team selects the low, moderate or high security control baseline from SP 800-53B. If the system processes personally identifiable information, it also takes the privacy baseline, which applies regardless of impact level and includes PT-1 from the PII Processing and Transparency family. Ask your authorizing body or contract which baseline and which release it expects, since FedRAMP and agency programs may set their own selections. The output is a baseline selection record listing every control and enhancement that starts in scope. It is done when that list is reviewed against the categorization and the privacy determination.
Tailor the baseline to the system
The team adapts the selected baseline using the tailoring activities in SP 800-53B. Controls can be designated as common, system-specific or hybrid, parameter values can be set (for example, account inactivity limits or log retention periods), and controls can be added through overlays or compensating measures where the baseline does not fit. Any control removed from the baseline needs a documented rationale and an approval from the authorizing official. The output is a tailoring decision log that shows each change and who approved it. The step is done when every removal and parameter choice has a reason on file.
Assign each control as organization, system or both
For every control in the tailored set, the team records whether the organization (O), the system (S) or both (O/S) implement it, using the designations in SP 800-53 Appendix C. Organization-level controls such as many policy and personnel controls are owned by the enterprise and inherited by systems, while system-level controls such as audit record content or cryptographic protection are built and configured for one system. Common controls provided by another team or cloud provider are recorded as inherited, with a reference to that provider's documentation. The output is a responsibility matrix that shows which party owns each control. It is done when no control lacks an owner.
Write the policy and procedures controls
Every family except Program Management opens with a -1 Policy and Procedures control, so the team writes the policy and the procedures that put each family into practice before writing system-level detail. Senior leadership approves the policies, and the control owners approve the procedures that describe how their controls run day to day. Program Management controls such as PM-1, the information security program plan, are written at organization level and referenced by every system. The output is a versioned set of policies and procedures with named owners and review dates. The step is done when each family has an approved -1 document that the assessor can read.
Implement and document each control
Engineers and control owners configure the system to meet each control, then write a control implementation statement that describes how the control is met, who operates it, and where the evidence is kept. Open-source platforms can generate much of this evidence, such as configuration baselines, audit logs and vulnerability scan results, but the team must confirm each tool's output maps to the control it supports. The output is the system security and privacy plan with an implementation statement for every control, along with the supporting artifacts. The step is done when a sample of statements can be traced to live configuration or logs.
Hand the control set to an independent assessor
The organization gives the complete package to an independent assessor, who plans testing with the SP 800-53A assessment procedures. For each control, SP 800-53A lists determination statements that the assessor checks using examine, interview and test methods against suggested assessment objects. The assessor does not write the implementation statements or decide the risk, and the authorizing official makes the authorization decision. The output is an assessment plan, which the assessor and the system owner agree before testing starts, and later a security assessment report with findings. The step is done when the assessor confirms the plan covers every control in the tailored set.
Where do families most often stall a first pass?
Most first assessment passes stall on the same few problems, and they cluster around documentation, ownership and evidence rather than technical controls. The cards below cover the gaps that repeat across families, with the fix for each in one sentence.
Missing -1 policy controls
Nineteen of the 20 families open with a -1 Policy and Procedures control, so a family without a current, approved policy and procedure set fails before any technical control is reviewed. Assessors look for an owner, an issue date, a review cycle and evidence that staff received the document. Check every family's -1 control against the CPRT entry before scheduling testing.
Unclear organization and system labels
Appendix C marks each control as implemented by the organization (O), the system (S) or both (O/S), and teams often leave these labels unset or copy them without checking. An O label means the evidence lives in a policy or process, while an S label means it lives in the system configuration. Confirm each label with the control owner and record the inherited and shared decisions in the system security plan.
Privacy controls skipped as out of scope
Teams often assume PII Processing and Transparency controls apply only to systems that are designated as privacy systems. The PT family is not allocated to the low, moderate or high baselines, but PT-1 sits in the privacy baseline, which applies to systems irrespective of impact level. Run the privacy baseline against every system that handles personal data, and document any control you decide not to apply.
Supply chain controls left to procurement
The SR family covers the supply chain risk management plan, provenance, supplier assessments and component authenticity, and procurement rarely produces that evidence on its own. Assessors ask for the plan, the supplier review records and the notification terms in contracts. Assign an SR control owner, link each supplier to a documented risk review, and keep the evidence with the system's control records.
Evidence kept in tickets
When screenshots, approvals and scan results sit in ticket threads, an assessor cannot trace them back to a control ID without reading each ticket. A control-indexed repository, where every artifact is tagged with the control and enhancement it supports, makes testing repeatable. Map each evidence item to a control ID, record the date it was collected, and link it from the assessment report.
Common questions about NIST 800-53 control families
How many control families and controls does NIST SP 800-53 Release 5.2.0 contain?
Release 5.2.0 contains 20 control families. Counted from NIST's OSCAL catalog, it has 324 base controls and 872 control enhancements, of which 300 base controls and 714 enhancements are active, with the rest withdrawn. The first ten families cover access control through media protection, and the other ten cover physical and environmental protection through supply chain risk management. Each family is a group of related controls, so the count matters less than knowing which families your system's baseline and tailoring decisions bring into scope. Confirm the current counts against the release you are working from, because NIST issues numbered releases over time.
Do all 20 control families apply to every system under SP 800-53?
No. The control baseline for the system's impact level, plus any tailoring and overlays, decides which controls apply. SP 800-53B defines low, moderate and high security baselines and a privacy baseline, and it selects different numbers of controls from each family. The PII Processing and Transparency family, for example, is not allocated to the low, moderate or high baselines and sits in the privacy baseline, which applies regardless of impact level. Your authorizing official or the governing contract sets the impact level, so start by categorizing the system before deciding which family controls you must implement and assess.
Can an implementation partner own a control family for us?
A partner can build, configure, document and test the technical and procedural work behind a family, but the organization still owns the control. The authorizing official keeps the risk decision, and only the organization can accept residual risk and assign responsibility for each control. Some controls can be inherited from a common control provider, which is a separate arrangement that still needs to be documented and agreed in writing. Before engaging a partner, confirm in writing which family work is delivered, which evidence the partner produces, and which decisions remain with your own staff.
How long does it take to map the control families to our systems?
NIST does not publish a duration for this work, and the time depends on the number of systems, the impact level, how much of the environment already has documented controls, and whether common controls are inherited. The mapping is usually scoped in stages: categorize the system, select the baseline, identify inherited and system-specific controls, then document ownership for each control. Ask any partner for a written scope that lists the systems, baseline, families and deliverables before agreeing a schedule, and ask which of your own staff time the plan assumes.
Can our own team map and implement NIST 800-53 control families in-house?
Yes, a capable internal team can do this, provided it has time, access to the system owners and a clear method for recording control ownership. The work includes reading the Appendix C control summaries to see which controls are implemented by the organization, the system or both, mapping each control to existing tooling, and writing the procedures that produce evidence. Many teams bring in outside help for specific gaps, such as logging design, configuration baselines or evidence automation, while keeping ownership and sign-off internal. Assess your staff's experience with federal authorization, your change volume and your deadline before deciding.
Does NIST issue a certificate for SP 800-53 control families?
No. NIST publishes SP 800-53 as a catalog of controls and does not certify organizations, products or people against it. Compliance is shown through an authorization to operate granted by an authorizing official in a federal or contractual context, and through an independent assessment against SP 800-53A procedures. Customers usually ask for the system security and privacy plan, the assessment report and the plan of action and milestones rather than a certificate. Ask any vendor that offers a NIST 800-53 certificate to show the authority behind it and whether it is an authorization decision or a marketing claim.
How DeployOpen maps families to your systems
DeployOpen works on NIST 800-53 control families by first agreeing in writing which systems and control families are in scope, then building and documenting the self-hosted open-source platforms that produce evidence for them. The organization keeps ownership of its controls, and independent assessors remain responsible for any assessment outcome.
How we scope
- Agree in writing which systems, boundaries and control families the engagement covers before any work starts.
- Map each in-scope family to the platforms and infrastructure that hold its evidence, such as logging, identity and configuration tooling.
- Confirm with your authorizing official and assessor which baseline and tailoring decisions the scope assumes.
- Agree deliverables and timelines in a fixed-scope document, with any ongoing support handled as a separate retainer.
How we build
- Deploy open-source platforms inside your own cloud accounts, data centers or air-gapped networks, not in a DeployOpen environment.
- Configure technical controls for access, logging, configuration baselines and encryption to match the agreed scope.
- Run security testing against the built systems to surface gaps before the independent assessment begins.
- Document each control's implementation, owner and evidence source so your team can explain it to assessors.
How we hand over
- Deliver system documentation, configuration records and evidence collection procedures to your named owners.
- Walk your security, compliance and platform teams through how each family's evidence is generated and where it is stored.
- Identify which controls remain with your organization, including policies, procedures and risk decisions, and mark them clearly.
- Provide a list of open items and recommended next steps so your team can track remediation after handover.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, sized to the written scope of the work.
- Keep evidence collection working as platforms are upgraded and as NIST releases updates to SP 800-53 content.
- Prepare systems and evidence for each assessment cycle, while the independent assessor issues any report or determination.
- Confirm with your team and assessor which support activities fall within your authorization boundary before engagement.
