What CA-2 control assessments require and why assessors focus on the plan
CA-2 asks the organization to select an appropriate assessor or assessment team, write an assessment plan that covers scope, procedures and roles, get that plan approved by the authorizing official, assess controls at a defined frequency, produce an assessment report and share the results. When an audit, authorization or customer contract is coming, the question an assessor asks is not only whether a control exists but whether someone independently checked that it is implemented correctly, operates as intended and produces the desired outcome. The assessment plan is usually the first document an assessor reads, because it shows what was tested, by whom and under whose approval.
The risk CA-2 addresses is controls that were correct on the day they were configured and have drifted since, with nobody verifying them. Three things usually make this hard. The first is that no assessment frequency is defined, so assessments happen only when someone remembers. The second is unclear assessor independence: if the person who built a control also assesses it, the result carries little weight, and the moderate and high baselines select CA-2(1) for independent assessors for this reason. The third is that reports stay with the technical team and never reach the decision makers who must accept the remaining risk. Confirm with your authorizing official who must approve the plan and what frequency your system's security documentation already states.
SP 800-53B Release 5.2.0 selects CA-2 for the low, moderate and high baselines and for the privacy baseline, so the requirement applies in every case where those baselines are in use. The organization owns its controls, its assessment scope and the acceptance of its results. An implementation partner can prepare systems, logs and evidence that an assessor will examine, but only the organization can approve the plan and act on the report, and only an independent assessor can issue the assessment findings.
Which systems and baselines a CA-2 assessment must cover
The scope of a CA-2 assessment follows the system's security category and the SP 800-53B baseline it is tailored from: low, moderate, high or privacy. The decisions below determine what the assessor will test, and each one must match the system security and privacy plan so the assessor examines the system the organization actually operates.
System boundary definition
The boundary sets which hardware, software, data stores, interfaces and people fall inside the assessed system. Every component inside the boundary needs assessment coverage under CA-2, and anything left out is a gap an assessor will question. Confirm that the boundary in the system security and privacy plan matches the boundary in the assessment plan, including network segments, administrative consoles and backup locations. Ask the assessor to confirm the boundary before testing begins.
Inherited and common controls
Some controls are implemented once for several systems and inherited by each one. The assessment plan must state which controls are inherited, which provider assessed them and where that assessment is documented. A system team that assesses inherited controls again wastes effort, while one that accepts them without evidence leaves a gap. Confirm the common control provider's assessment results and their date before scoping them out of the system assessment.
Third-party and cloud-hosted components
Managed databases, identity services, SaaS tools and cloud infrastructure may implement parts of a control while the organization retains others. The assessment must separate what the provider covers from what the organization must show itself, such as configuration, access reviews and log retention. Request the provider's assessment or attestation material and confirm which control responsibilities it actually covers. Document any responsibility the provider does not cover as an open scope item.
Privacy baseline controls
The privacy baseline applies regardless of impact level, so systems that process personally identifiable information carry privacy controls into the assessment even when their security baseline is low. The assessment plan must name which privacy controls apply, who owns them and which assessment procedures test them. Confirm with the privacy office that processing purposes and data categories are current before the assessor scopes these controls.
Assessment frequency by control family
CA-2 requires assessments at a defined frequency, and that frequency can differ by control family or by control. The organization sets it, documents it in the plan and applies it consistently to each family. Highly volatile areas such as vulnerability management may need shorter cycles than stable policy controls. Confirm the chosen frequencies with the authorizing official, because the assessor will test whether assessments actually ran on that schedule.
Ownership of cross-system controls
Some controls span several systems, such as shared identity services, logging pipelines or incident response processes. Each one needs a named owner who answers for its implementation and who supplies evidence to every assessment that relies on it. Without a clear owner, each system team may assume another team tested the control. Record the owner, the systems that depend on the control and the evidence location in the assessment plan.
How CA-2(1) and CA-2(2) change the assessor you hire
CA-2(1) requires independent assessors, and it is selected in the moderate and high baselines. Under SP 800-53B Release 5.2.0, a system at moderate or high impact cannot rely on an assessment performed only by the people who built or run the controls being tested. In practice, independence means the assessor is not the person who designed, implemented, configures or operates the control, and does not report to the same manager who is accountable for its performance. A platform engineer who wrote the Wazuh or Fleet rule set should not be the one who judges whether that rule set works. An in-house team can still qualify if its members sit outside the control's delivery chain, have their own reporting line to the authorizing official or a senior risk owner, and can show they did not prepare the evidence they are testing. Confirm this with your authorizing official before the assessment plan is written, because the decision affects who you staff and who you can pay.
CA-2(2) adds specialized assessments, and SP 800-53B selects it only in the high baseline. It asks the organization to use specialized assessment techniques and tools beyond the general review of documents and interviews. Typical additions include technical testing of particular components, such as configuration reviews of hypervisors or identity providers, code or container image analysis, and validation of cryptographic implementations. The assessment procedures in SP 800-53A still apply, but the assessor may need skills and tooling that a general audit team does not hold. Illustrative example: a high-impact system that uses a self-hosted identity platform might need a specialist to test token handling and session controls directly, not only to read the configuration export. Ask each candidate which specialized methods they would apply, which tools they would run, and what evidence they would produce from those tests.
The organization decides how both enhancements are met in its own environment. NIST describes the Rev. 5 controls as flexible and implemented within an organization-wide risk management process, so the choice of assessor, the depth of specialized testing and the justification for any in-house independence are management decisions that must appear in the assessment plan and be approved by the authorizing official. An implementation partner can prepare systems, configuration evidence and test environments, and can help scope specialized work, but the partner should not be the assessor for its own build. Where a specialist firm or independent tester performs the testing, the organization should confirm in writing who is responsible for the assessment, what each party delivers, and how findings flow into the plan of action and milestones.
How an assessor tests CA-2 under SP 800-53A
This table maps the assessment steps an assessor follows for CA-2 under SP 800-53A Rev. 5, the method used at each step, the objects examined, the evidence to prepare and a finding that often appears. Read it as a preparation checklist: the assessor checks that the plan is approved, that assessments run at the defined frequency and that the report is shared with the right recipients.
| Assessment step | Method | Objects and evidence to prepare | Common finding |
|---|---|---|---|
| Plan approval and content | Examine | Control assessment plan showing scope, procedures, roles and the authorizing official's approval record | Plan exists but has no dated approval from the authorizing official, or omits roles |
| Assessor selection | Interview | Personnel with control assessment responsibilities, plus the written selection rationale for the assessor or team | Assessor independence is asserted but not documented for the chosen team |
| Assessment frequency | Examine | Defined assessment schedule and records of prior assessments showing they ran at that frequency | Frequency is defined in policy but assessments were run irregularly or not at all |
| Assessment of correct implementation, operation and outcome | Test | Mechanisms supporting control assessment and plan development, such as tooling outputs and test records, with a sample of controls | Testing confirms configuration exists but not that it operates or produces the intended outcome |
| Assessment report content | Examine | Control assessment report with findings per control, linked to the plan and to the POA&M where weaknesses are found | Report lists results without the procedures used or the evidence reviewed |
| Sharing of results | Interview | Personnel who receive results, plus distribution records showing the report reached the authorizing official and other defined recipients | Report is stored in a repository but no distribution record exists for the required recipients |
Implementing CA-2 in six steps and what each step produces
The sequence moves from a confirmed scope to an assessor-run, approved assessment and a shared report, so that each output can be shown to an assessor, an authorizing official or a customer. Each step depends on the one before it, and skipping ahead usually means evidence cannot be defended later.
Confirm the baseline and assessment scope
Start by confirming which SP 800-53B baseline applies to the system (low, moderate, high or privacy) and therefore which CA-2 requirements and enhancements are in force. Record the system boundary, the controls in scope and any tailoring decisions, including inherited common controls. The output is a scope statement that names the system, the baseline, the included controls and the excluded components with reasons. Confirm the scope with the system owner and the authorizing official's office before anyone selects an assessor, because every later document refers back to it.
Select the assessor or team
Choose an assessor or assessment team that has the skills and suitable independence for the system and its impact level. Document who was considered, why the selection was made and how the assessor's role is separated from the people who implemented the controls. Where the moderate or high baseline applies, decide whether CA-2(1) on independent assessors must be met, and where the high baseline applies, decide whether CA-2(2) on specialized assessments (such as penetration testing or red team work) is needed. The output is an assessor selection record that states the decision on each enhancement. Confirm the approach with your assessment authority, because the requirement is defined in your own program terms.
Write the control assessment plan
The assessor, with input from the control owners, drafts the assessment plan. It should cover the scope from step one, the assessment procedures to be used (for example, the examine, interview and test methods in SP 800-53A), the roles and responsibilities of each person involved, the assessment objects such as configuration records, logs and tooling, and the schedule. Map each planned procedure to the control it tests so an assessor can trace coverage. The output is a draft plan with a version number and date. Keep it under change control, since any later change must be visible to the approver.
Obtain the authorizing official's approval of the plan
Send the draft plan to the authorizing official, who must approve it under CA-2. Review should check that the scope matches step one, that the procedures cover the controls in the baseline, and that the roles are clear. Record the approval with the name of the approver, the date and the plan version approved. The output is a signed or recorded approval tied to a specific plan version. The common gap here is approving a plan after testing has already started, or revising the plan mid-test without a new approval. That leaves the results without a documented basis, and an assessor may have to rerun work. Freeze the approved version before testing begins, and route any change back through approval with a note explaining the reason.
Run the assessment at the defined frequency
Carry out the assessment as the approved plan describes, at the frequency your program defines. For each control, the assessor determines whether it is implemented correctly, operating as intended and producing the desired outcome, and records the method used and the evidence reviewed. Dated records of each test, such as configuration exports, interview notes, scan results and sample tickets, should be stored with the assessment file. Open-source tooling can help produce some of this evidence. For example, vulnerability detection in Wazuh or software inventory matching in Fleet can generate dated output that the assessor can review, although the assessor still decides whether the result satisfies the control. The output is a set of dated test records linked to each control.
Write the assessment report and share the results
The assessor writes the report that records, for each assessed control, the result, the evidence relied on and any findings or weaknesses. The report feeds the plan of action and milestones (CA-5) for anything that needs remediation. Once the report is final, the organization shares the results with the people and bodies named in its program, which should be listed in a distribution list that includes the authorizing official and the system owner. Record the date of each distribution. The output is a signed assessment report and a distribution record showing who received it and when. Confirm with your assessor whether the report must be issued under their own signature, since the organization owns its controls but the independent assessor issues the report.
Evidence that passes a CA-2 assessment and how to keep it current
A CA-2 assessor looks for a chain of documents that agree with each other: who was chosen and why, what was planned and approved, what was tested and found, and who received the results. The cards below describe each artifact, what the assessor checks and how to keep it accurate between assessments. The assessor decides whether any artifact is sufficient.
Approved assessment plan
The plan sets scope, assessment procedures, roles and the assessment objects to be examined, interviewed or tested. Check that it names the controls in the system boundary, the methods used for each control and the authorizing official's approval with a date. Between assessments, store the plan under version control, record each revision with a change note, and re-approve it when the boundary or system components change, since a plan that describes a retired architecture weakens the report that follows.
Assessor selection and independence record
This record shows who performed the assessment, how they were chosen and whether they had any role in building or operating the system. Assessors look for a documented selection decision, the assessor's qualifications for the assessment type and a statement of independence where the baseline requires independent assessors. Keep the record alongside the plan, update it whenever the assessment team changes and file any conflict-of-interest review so it can be produced without reconstruction.
Assessment report with findings
The report records the results for each assessed control, the methods used, the objects reviewed and the findings with their risk context. Assessors check that every planned control has a result, that findings trace back to the plan and that the report is dated and approved. Between assessments, keep prior reports intact, link each open finding to the POA&M entry that tracks its remediation and avoid editing old findings in place.
Distribution record for shared results
CA-2 requires results to be shared with designated organizational officials. Assessors look for a record of who received the report, when it was sent and which decisions the recipients made in response, such as an authorization decision or a remediation directive. Maintain a distribution list that matches current role holders, keep transmittal records and note any restricted or redacted versions so the recipients of each copy are known.
Dated test and examination records
Examine and test evidence, such as configuration exports, interview notes and scan outputs, shows what the assessor actually saw. Check that each record carries a collection date, the system state at that time and the control it supports. Run scheduled exports from the tools that produce them, store raw outputs in write-once or versioned storage and label any manual screenshot with its source and time, so the assessor can verify the evidence was collected during the assessment window.
Assessment frequency schedule
CA-2 requires assessments at a frequency the organization defines, so the schedule is the proof that the defined frequency is being followed. Assessors compare the schedule with completed assessment dates and the authorization period. Maintain it as a controlled document, update it when the organization changes the frequency and log any missed or rescheduled assessment with the reason and approval.
Who does what in a CA-2 assessment: your team, a partner and the assessor
Your organization owns the controls. Under CA-2, your team selects or approves the assessor, reviews and approves the assessment plan with the authorizing official, makes system owners and control operators available for interviews and testing, and receives the assessment report. The report and its findings then feed your remediation decisions and the plan of action and milestones. No outside party can accept risk on your behalf.
- Assessor selection: Decide what independence and skills the assessor needs, and document why the chosen team qualifies.
- Plan approval: Confirm scope, procedures and roles in the assessment plan before testing starts, and obtain the authorizing official's approval.
- Operational access: Name the people who run each control so assessors can interview them and observe the mechanisms in use.
- Report ownership: Review the assessment report, decide which findings to accept, remediate or track, and share results with the people who need them.
Before testing begins, check that your approval record, scope statement and named control owners are complete, because gaps there are the most common reason an assessment slips.
An implementation partner such as DeployOpen prepares the systems that the assessment will examine and assembles the evidence assessors will ask for. For CA-2 this usually means drafting the assessment plan for your review, organizing configuration exports, logs and scan results, and running security testing that produces findings for the assessor to evaluate. The partner works inside your infrastructure and does not issue any report or certificate.
- Plan drafting: Prepare a draft assessment plan that maps scope, procedures and roles to the systems in the boundary, for your team to edit and approve.
- Evidence preparation: Set up collection so that configuration baselines, access reviews and monitoring outputs can be produced on request.
- Security testing: Run application, infrastructure or penetration testing that feeds the assessment, with written scope and rules of engagement.
- Documentation support: Help draft the assessment report inputs, but leave the assessor's findings and conclusions to the assessor.
Independence limits apply. If the partner built or configured a control, it should not be the party that assesses that control. Ask who on the partner side will be involved, and confirm that the assessor has no role in building the systems it tests.
The independent assessor tests whether controls are implemented correctly, operate as intended and produce the desired outcome, using the procedures in the assessment plan. It examines documents and configurations, interviews personnel, and tests mechanisms. The assessor then records findings and writes the assessment report. Only an independent assessor, auditor or certification body issues reports or certificates of this kind.
- Procedure execution: Apply the examine, interview and test methods in the approved plan to each selected control.
- Findings: Record weaknesses and deficiencies with the evidence behind them, so your team can route them into the plan of action and milestones.
- Report issuance: Produce the assessment report with the conclusions the assessor is able to support.
- Independence: Keep a clear separation from anyone who designed, operated or remediated the controls under review.
When selecting an assessor, ask for written confirmation of independence, the qualifications of the people who will perform the work, and how they will handle conflicts raised by a partner that also prepared evidence.
What a CA-2 assessment costs in money and effort
This table compares the main cost components of a CA-2 control assessment, showing who is paid, whether each cost is one-time or recurring, what pushes it up and how to contain it. NIST does not estimate compliance costs, so use the table to shape a written quote rather than to predict a total.
| Cost component | One-time or recurring | What drives it up | How to keep it down |
|---|---|---|---|
| Assessor or assessment team fees | Recurring, per assessment cycle | Number of systems in scope, baseline selection, CA-2(1) independent assessors, CA-2(2) specialized assessments, number of controls assessed | Agree a defined scope, reuse prior results where the authorizing official accepts them, and confirm assessor independence before comparing bids |
| Internal staff time to write the assessment plan | One-time for the first plan, recurring when revised | Scope breadth, number of roles to document, new system components, and the number of review rounds | Build the plan from existing system security plan content and keep procedures traceable to SP 800-53A |
| Internal staff time to collect evidence | Recurring, per assessment | Number of examine, interview and test objects, manual evidence gathering, and missing logs or inventories | Automate evidence collection from logging, configuration and vulnerability tooling where it already exists |
| Authorizing official review time | Recurring, at plan approval and report acceptance | Number of review cycles, size of the plan and report, and unresolved assessment questions | Share a draft plan early and agree the report format before fieldwork begins |
| Tooling or licenses | Often recurring, sometimes one-time setup | Number of tools, licensed endpoints, and whether open-source tools need hosting and support | Confirm license terms and hosting costs for each tool, and check whether open-source options meet the evidence need |
| External testing that feeds the assessment | Recurring, per testing cycle | Scope of testing, whether penetration testing results are used, and testing frequency set by the organization | Align testing scope with the assessment plan so results count as evidence without duplicate work |
| Report upkeep and sharing | Recurring, after each assessment | Frequency of assessments, number of recipients, and changes to controls between cycles | Keep the report structured so findings flow directly into the plan of action and milestones |
Which open-source tools produce CA-2 evidence
CISO Assistant is a governance, risk and compliance platform released under AGPL-3.0-only. It ships more than 200 frameworks, including ISO 27001, NIST CSF, SOC 2, PCI DSS, NIS2, DORA and GDPR, and it can run audits and compliance assessments against them with automatic mapping between frameworks. For CA-2, its value is in organizing the record around the assessment rather than in testing the controls themselves.
- Assessment plan tracking: Record the scope, procedures, roles and assessor for each assessment cycle so the plan the authorizing official approved is visible in one place.
- Assessment record: Store the results for each control, the assessment method used and the supporting evidence references, so reviewers can trace findings back to the plan.
- Report preparation: Use the stored results as the basis for the assessment report and for sharing results with stakeholders.
- Framework mapping: Where an organization also tracks other frameworks, reuse the mapped results instead of recording the same assessment twice. Check each mapping against NIST's own material before relying on it.
- Licensing: AGPL-3.0-only obligations apply if you modify and distribute or host the software for others. Have counsel review the license against your deployment model.
Confirm the current framework library, assessment features and export options in your own environment before you design the workflow around them.
Wazuh is an open-source security platform licensed under GPL-2.0-only. Its vulnerability detection module correlates the software inventory that each agent collects with the Wazuh CTI vulnerability repository, or with a locally hosted offline copy, to identify vulnerabilities in the operating system and installed applications of monitored endpoints. For CA-2, this output can support the technical evidence an assessor examines when judging whether vulnerability assessments are performed on schedule.
- Endpoint inventory: Agents report installed operating system and application software, which gives assessors a record of what was in scope at the time of the assessment.
- Vulnerability findings: Detection results list vulnerabilities by endpoint, which can feed the assessment report and the plan of action and milestones.
- Offline operation: A locally hosted copy of the vulnerability content supports environments that cannot reach external feeds, such as air-gapped networks. Confirm how and when the offline copy is updated.
- Scan history: Retained detection output shows that assessments ran at the defined frequency, which is the kind of record assessors ask for.
- Licensing: GPL-2.0-only terms apply to distributed or modified versions. Review them with counsel before embedding Wazuh in a commercial product.
Confirm the current detection coverage, content sources and retention settings in your own environment before relying on them as assessment evidence.
Fleet is an open-source device management platform released under the MIT license. It detects vulnerable software on enrolled hosts by matching installed software against sources including the NVD, OVAL definitions, Microsoft security bulletins, Amazon Linux advisories and OSV. For CA-2, Fleet supports evidence about which hosts were checked and what software was found on them, which assessors can compare against the approved assessment plan.
- Host-level software inventory: Fleet records installed software on enrolled hosts, which defines the population an assessment covered.
- Multiple vulnerability sources: Matching against NVD, OVAL, Microsoft bulletins, Amazon Linux advisories and OSV gives assessors a view across several operating system families. Confirm which sources apply to your fleet.
- Vulnerability processing records: Results can be reviewed and tracked over time, supporting the plan of action and milestones.
- Coverage gaps: Hosts that are not enrolled do not appear in results. Reconcile enrollment against the system inventory before the assessment starts.
- Licensing: The MIT license is permissive, but your own customizations and hosted service terms still need review.
Confirm the current source list, supported platforms and reporting options in your own environment before you present Fleet output to an assessor.
CA-2 control assessments questions buyers ask
How much effort does CA-2 take to meet?
Effort depends on the size and boundary of the system, how many controls are in the selected baseline, how mature the existing evidence is, and how many assessors and stakeholders must take part. No supplied figure gives a duration, so ask for one in writing. In practice the work falls into four blocks: selecting and documenting the assessor, writing the assessment plan and getting the authorizing official's approval, running the assessments against the examine, interview and test methods, and producing and sharing the report. A system with current configuration baselines, scan results and a maintained system security plan usually needs less preparation than one where evidence has to be reconstructed. Ask the partner to break the quote into these blocks so you can see which parts are your staff's time and which are external.
Can an in-house team perform CA-2 assessments?
Yes, CA-2 does not by itself require an external organization, but the assessor must be selected appropriately and the authorizing official must approve the plan. An in-house team can assess controls when it has the skills and enough separation from the people who operate the system. Independence matters more at higher baselines: CA-2(1) is selected in the moderate and high baselines and concerns independent assessors, while CA-2(2) for specialized assessments is selected only in the high baseline. Ask whether your team can document its independence and whether the authorizing official accepts that arrangement. An implementation partner can prepare the evidence and test scripts your team uses, but it does not issue the assessment report on your behalf.
Does the assessor have to be independent?
Independence is required only where the baseline or your authorization model selects CA-2(1), which covers the moderate and high baselines in SP 800-53B Release 5.2.0. Independence means the assessor is not the team that designed, built or runs the control, and that the assessor can report findings without pressure from those teams. Within the high baseline, CA-2(2) adds specialized assessments such as penetration testing or red teaming, which need people with the relevant skills. Confirm with your authorizing official which assessor arrangement they will accept, and get that written into the assessment plan before work begins.
How often must control assessments run, and what does the frequency depend on?
CA-2 requires assessments at a frequency the organization defines, so the number is set by your own policy and by the authorization terms that apply to the system. The frequency depends on the system's impact level, the baseline it is assessed against, the rate of change in its configuration, any contractual or regulatory requirement, and how much continuous monitoring under CA-7 already covers. Assessment runs can be scheduled, triggered by significant change, or both. Write the chosen frequency into your policy and plan so an assessor can test it. Ask any partner to show how the schedule maps to the controls it covers.
What will an assessor ask for in the first week?
An assessor usually starts by asking for the artifacts that define the system and its authorization boundary: the system security and privacy plan, the current control implementation statements, the approved assessment plan, and the most recent assessment report. They will also request configuration baselines, the list of assessment objects, scan results, the plan of action and milestones, and the names of people who hold assessment, operations and authorizing roles. Interviews are scheduled early so that people can explain how controls work. Prepare a single evidence index before the first meeting, because missing or contradictory documents tend to consume the first week.
What does the partner prepare, and what does the assessor issue?
The organization owns its controls and its authorization decisions. A partner such as DeployOpen can prepare systems, configuration, test tooling, documentation and evidence for the assessment, and can support the assessment plan and report drafts within the agreed scope. Only the independent assessor issues the assessment report and its findings, and only the authorizing official accepts risk and grants authorization. Be specific about this split in the scope document so no one assumes that preparation equals assessment. The quote should list each deliverable and who signs it.
How does CA-2 link to CA-5 and CA-7?
CA-2 produces the assessment report, which is the main input to the plan of action and milestones under CA-5. Each weakness or deficiency found during assessment should be recorded in the POA&M with a remediation plan, owner and milestone, and the POA&M is then updated as fixes are verified. CA-7 continuous monitoring supplies ongoing evidence between formal assessments, so it can reduce how much each CA-2 cycle must rediscover and can trigger reassessment when monitoring shows a change in risk. Ask a partner to show how assessment findings, POA&M entries and monitoring outputs share identifiers so an assessor can trace them.
How DeployOpen prepares systems and evidence for CA-2 assessments
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, then prepares the systems, controls and evidence that an independent assessor will examine for CA-2. We do not select, approve or issue findings for the assessor, and the organization keeps ownership of its controls and its assessment decisions.
How we scope
- Agree in writing which systems, boundaries and SP 800-53 controls the CA-2 work covers before any build starts.
- Confirm which baseline applies, low, moderate or high, and which CA-2 enhancements the organization has selected.
- Record who owns each control, who the authorizing official is and which assessor the organization has chosen.
How we build
- Configure the self-hosted platforms in your cloud accounts, data centers or air-gapped network to match the agreed scope.
- Set up tooling that collects control evidence, such as software inventories and vulnerability findings, for the assessor to examine.
- Test the evidence pipeline so that assessment objects, including the assessment plan and report, can be produced on a defined schedule.
How we hand over
- Deliver written documentation of the assessment inputs, configurations, evidence sources and known gaps for the organization's review.
- Provide a handover package that maps evidence locations to the CA-2 determination statements and related controls.
- Support the organization in sharing the approved assessment plan and results with the authorizing official and the assessor.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope engagement ends.
- Update evidence collection when the organization changes systems, selected baselines or the SP 800-53 release in use.
- Confirm with your assessor and authorizing official what they need, since their requirements decide what counts as sufficient evidence.
