What CM.L2-3.4.4 security impact analysis requires before a change goes live
CM.L2-3.4.4 asks for one thing: the security impact of a change must be analyzed before that change is implemented. If you are a defense contractor preparing for a Level 2 assessment, the question an assessor will put to you is not whether you have a change process in general but whether someone assessed what a specific change could do to your security controls before it reached production. The requirement is the Level 2 version of NIST SP 800-171 Rev. 2 requirement 3.4.4, a derived requirement in the Configuration Management family. CMMC Level 2 carries 110 requirements, and this is one of them. Its basis in Rev. 2 matters because the CMMC rule incorporates that revision, even though NIST has since published Rev. 3. NIST SP 800-171A assigns 3.4.4 a single assessment objective: the security impact of changes to the system is analyzed before they are implemented. That timing is the point. An analysis written after the change is live does not satisfy it.
The risk behind the requirement is quiet drift. A firewall rule added to fix a vendor connection, a logging agent disabled to free up disk space, or a new service account granted broad rights can each weaken controls the system security plan describes, and none of them looks dramatic in a ticket. The analysis is meant to catch that before it happens. It should ask which controls the change touches, whether it introduces a new risk the SSP does not address, and whether the SSP, baseline or configuration documentation must change with it. The DoW CMMC FAQ (July 2026) treats a new risk not addressed in the existing SSP as a probable sign of a significant change, which gives you a practical trigger to write into your procedure.
Because 3.4.4 is worth 1 point, it is easy to under-document, and that is where contractors lose it. Teams often run the analysis informally in a meeting and record only the approval. An assessor will look for the analysis itself: a documented, repeatable step tied to each change record, with the reviewer's findings and the decision that followed. Confirm with your assessor or your C3PAO what form they expect, since the assessment guidance and SP 800-171A list documentation, tool outputs and change records as possible evidence. Plan to have the analysis fields sit inside the same workflow as change approval, so the evidence is produced as a by-product of normal work rather than reconstructed before an assessment.
Which changes and systems need a security impact analysis
CM.L2-3.4.4 applies to changes that touch systems handling CUI, including the components that enforce the boundary and the third-party services those systems depend on. The decisions below determine how much work each change creates and what the assessor will ask to see.
Systems that process or protect CUI
Start with the system security plan boundary. Every system that stores, processes or transmits CUI, plus the security tooling that protects it (identity, logging, endpoint protection, firewalls), is in scope for analysis. Changes to systems outside that boundary are not automatically exempt, though. If a shared directory, jump host or build server can reach CUI, the assessor may treat it as part of the boundary. Confirm this with your SSP before drawing the line.
Third-party managed components
Managed service providers, hosted platforms and cloud services often push changes on their own schedule. Your analysis still applies to changes they make that affect your CUI environment, so you need a route to receive their change notices and assess them. Ask providers in writing how they notify you of changes, how far in advance, and whether they will share the information needed for your analysis.
Routine patches and updates
Routine patches are the most common source of unanalyzed changes. Decide in advance which patch classes get a standard, documented impact review (for example, a template that confirms the patch does not alter security functions, authentication or encryption) and which need a full review. A patch that changes how a security function works is not routine, even if the vendor labels it as a fix.
Cloud and configuration changes
Cloud consoles and infrastructure-as-code make configuration changes quick and easy to miss. Security group rules, identity policies, storage encryption settings and logging configuration all alter the security posture of a CUI system. Route these changes through the same analysis as hardware or software changes, and record them in the same change records so the assessor can trace them.
Changes to the SSP boundary
Any change that adds or removes a system, connection or data flow from the CUI boundary is significant by definition. Analysis should confirm whether the SSP, network diagrams and data flow documentation still describe the environment accurately. Treat boundary changes as a trigger for SSP review, not only as a configuration task.
New risk not addressed in the SSP
The DoW CMMC FAQ (July 2026) states that a new risk not addressed in the existing SSP probably indicates a significant change. Use this as a test during analysis: if the change introduces a risk the SSP does not describe, the change needs formal review, SSP updates and documented approval before implementation. Record the reasoning so the assessor can see how the decision was reached.
How an assessor tests the security impact analysis process
The first thing an assessor looks at is whether the organization has a defined way of analyzing security impact before a change goes live. NIST SP 800-171A assesses CM.L2-3.4.4 with one objective: the security impact of changes to the system is analyzed before they are implemented. To meet it, the organization needs a documented procedure that says who performs the analysis, what it considers (such as affected assets, data flows, authentication paths, logging and the security configuration baseline), how it records the outcome, and what triggers a fuller review. The assessor compares that procedure against the System Security Plan and the change workflow to confirm they describe the same process.
- Defined roles: The procedure names who performs the analysis and who approves it, including the security function's role.
- Scope triggers: It states what counts as a change that needs analysis, such as new software, configuration changes or new network paths.
- Analysis content: It lists the questions the analysis answers, for example whether the change alters a security control or introduces a new risk.
- Link to the SSP: It explains how a new risk not addressed in the existing SSP is handled as a potential significant change.
- Version control: The procedure carries an owner, a version and a review date.
Check that the written process and the SSP agree, and that every named role exists in the current organization chart.
Assessors do not stop at the document. They select a sample of changes from the period under review and trace each one back through the process. The purpose is to confirm that the written procedure is what actually happens. Assessors typically look for changes that were analyzed before implementation, not after, and they check that the analysis reflects the change as it was actually made. A process that works only for the changes an organization remembers is not enough.
- Selection: The assessor chooses changes across different systems and change types, including emergency changes if any occurred.
- Timing: For each sample, the analysis date should precede the implementation date in the record.
- Accuracy: The analysis should describe the change that was implemented, including any scope growth during the work.
- Outcome: The record shows the decision reached, the reasons, and any required follow-up such as SSP updates or new controls.
- Exceptions: Any change implemented without a prior analysis should have a documented reason and a corrective step.
Before an assessment, pull a sample of recent changes yourself and trace each one from request to analysis to implementation.
SP 800-171A lists the evidence an assessor may examine for 3.4.4: the security impact analysis procedures and documentation, the analysis tools and their outputs, change control records, and audit records. The assessor uses these to verify that the analysis happened, when it happened and what it found. Where the analysis relies on scanners, configuration checks or diff tools, the assessor may also ask how those outputs fed into the decision. Ticketing and change systems, when configured to record approvals and timestamps, often provide much of this evidence.
- Analysis records: Completed analysis forms or tickets with the reviewer, date and conclusion.
- Tool outputs: Scanner, configuration or dependency reports attached to the change, with the date they were generated.
- Change control records: Approval history showing that the analysis was complete before the change was authorized.
- Audit records: System logs that confirm when the change was made and by whom, so the timeline can be checked.
- Retention: Records kept long enough to cover the assessment period, with integrity controls on the records themselves.
Confirm with your assessor which systems and tools they expect to see, and whether they want exports or direct read access.
Assessors may also test the process itself rather than only the paperwork. In practice, this means asking the people who perform analyses to walk through a recent example, explain how they decided the depth of review, and describe what they would do if the analysis revealed a significant security change. The assessor may compare what staff say with what the records show. Gaps between the description and the evidence are a common finding, so the organization should rehearse these walkthroughs before the assessment.
- Walkthroughs: Staff explain a sample analysis step by step, including the tools they used.
- Judgment checks: Staff describe how they decide whether a change is significant enough for a fuller review.
- Escalation: The assessor asks what happens when an analysis finds a new risk not covered by the SSP.
- Consistency: Different analysts reach comparable conclusions for similar changes.
- Improvement: Lessons from past analyses feed back into the procedure.
Run a dry-run walkthrough with the people who perform the analysis, and fix any step they cannot explain from the documentation.
Implementing security impact analysis in the change workflow
This sequence turns CM.L2-3.4.4 into a repeatable part of change handling, so every change is screened for security impact before it reaches production and each significant change leaves a written record that the SSP reflects. The outputs at each step are what an assessor will ask to see.
Define what counts as a change
Write a scope statement that lists the change types the workflow covers, such as hardware swaps, firmware updates, operating system patches, configuration edits, new software, network rule changes and cloud resource modifications, and name the systems in the CUI boundary they touch. Assign an owner for the definition, usually the change manager working with the system security officer. Done means a versioned change policy exists, is approved by the organization, and is linked from the change procedure. Ask your assessor or consultant how they expect scope to match the system security plan boundary.
Create a written impact analysis template
Build one template that every change request must complete before approval. Include fields for the affected components and their security functions, the controls in the system security plan that the change could touch, new data flows or exposures, required changes to authentication, logging or encryption, rollback steps, and a yes or no decision on whether the change is significant. Store the template in the same system as change records so the two are linked. Done means the template is approved, version controlled and used on at least one real change request before the first assessment.
Set the significance test
Document the criteria the analyst uses to decide whether a change is significant. The DoW CMMC FAQ (July 2026) indicates that a new risk not addressed in the existing SSP probably signals a significant change, so make that question an explicit field on the template. Add further triggers that fit your environment, such as changes to boundary devices, identity providers or CUI storage. Done means the criteria are written down, the people applying them are named, and the criteria cover the SSP as the reference point.
Route every change through an approval gate
Configure the workflow so that no change moves to an implementation state until the impact analysis is complete and signed off by a reviewer who did not write it. Use the change board, or an equivalent approver, for changes flagged as significant. Ticketing platforms such as GLPI can hold change records with approval states, though you should confirm that the gate can block implementation in your environment rather than only record it. Done means a sampled change cannot reach production without a completed analysis and recorded approval.
Analyze the security impact before implementation
The analyst completes the template, tests the change in a non-production environment where practical, and records the results of any scans, configuration checks or test outputs as attachments. The analysis must be finished before the change is implemented, because the requirement is about analysis before implementation. Done means the completed template, test outputs and reviewer sign-off are attached to the change record with timestamps that show the order of events.
Record the outcome and any required mitigations
Record whether the change is significant, which SSP controls were reviewed, and the mitigations required before go-live, such as a new logging rule or a revised access restriction. Link each mitigation to a task that is closed before or at implementation. Done means every analysis has a documented outcome, every mitigation has an owner and status, and no open mitigation is left without a tracked item.
Update the SSP when a significant change is found
When an analysis finds a significant change, update the system security plan to reflect the new component, risk, control implementation or boundary, then record the SSP revision number on the change record. Confirm the SSP update is approved under your document control process. Done means the SSP revision and the change record refer to each other, and the SSP describes the system as it now operates. Confirm with your assessor how they will sample these records.
Review the change log for gaps
Periodically sample closed change records against the change log, system inventory and deployment records to find changes implemented without an analysis, or analyses that were completed after implementation. Feed any gaps into corrective action and training. Done means the review has a written schedule, a named reviewer, and recorded findings with corrective actions tracked to closure.
Evidence that passes a security impact analysis test
An assessor testing CM.L2-3.4.4 looks for proof that analysis happened before each change, not a policy that says it should. The cards below cover the artifacts that carry that proof and the habits that keep them current between assessments.
A documented analysis procedure
The written procedure defines what triggers an analysis, who performs it, which system documentation is consulted, and how the result is recorded. Assessors read it first, then test whether practice follows it. Confirm that the procedure names the SSP as the reference point, since the DoW FAQ treats a new risk not addressed in the SSP as a probable sign of a significant change. Keep the procedure under version control with an approval date.
Completed analyses dated before implementation
Each significant or potentially significant change needs its own analysis record showing the affected components, the security functions touched, the risks identified and the decision taken. The timestamp must precede the implementation date. Assessors compare these dates against change logs, so an analysis written after deployment will not demonstrate the requirement. Ask for a sample of recent changes and check the sequence for each one.
Change tickets linked to analysis
A change record should reference the analysis that supports it, so an assessor can move from a production change to the reasoning behind it without searching. Link fields, required attachments or approval gates work well here. Changes that skip analysis should be visible in the ticket system as exceptions with a named approver. This linkage also feeds the change control evidence reviewed under CM.L2-3.4.3.
Tool outputs that support the analysis
Scanner results, configuration compares, dependency reports and test results can show what a change affects. SP 800-171A lists analysis tools and their outputs as potential evidence. Keep the output files with the analysis record, or store a reference and hash, so the tool result remains available when the analysis is reviewed. Confirm which tools your environment actually runs and that their outputs are retained for the period your contract requires.
Audit records of the process
Audit logs show whether tickets were opened, analyses attached and approvals given in the order the procedure requires. They also show when a change reached production. Protect these logs from edit, and confirm they are reviewed. Gaps in the sequence, such as an approval timestamp earlier than the analysis, are the findings assessors most often raise, so check for them before the assessment.
Final evidence and current records
A requirement is met only when every applicable objective is satisfied with evidence in final form. Drafts, unsigned analyses and placeholder fields do not count. Set a recurring review that closes open analyses, confirms the SSP reflects changes made, and archives superseded versions. Between assessments, sample recent changes monthly to confirm the record still matches what happened in production.
What meeting CM.L2-3.4.4 costs in money and effort
This table lists each cost component of running security impact analysis under CM.L2-3.4.4, who is paid for it, whether it is one-time or recurring, and what moves it up or down. Use it to structure a request for quote, since DeployOpen figures come from the written scope rather than a published price list.
| Cost component | Who is paid or who bears the cost | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Change ticketing or change tooling licenses | Commercial tool vendor, if a proprietary change tool is used | Recurring (subscription or seat fees) | Number of named users and approvers. Self-hosted open-source options such as GLPI, which includes ITIL-style change handling, can remove this license line, though hosting and administration remain |
| Engineering time to write impact analysis templates | Internal staff or an implementation partner under a written scope | One-time, with periodic revision | Number of system types and change categories. Fewer, well-defined templates keep this low, while many bespoke templates raise it |
| Engineering time to analyze each change | Internal engineers, security staff or contractors | Recurring, per change | Change volume and system complexity. Standard change types with pre-written analysis checklists reduce effort per change |
| Change board reviewer time | Internal reviewers such as security, system owners and operations | Recurring, per review cycle | Frequency of change board meetings, size of the board and how many changes need full rather than expedited review |
| SSP and documentation upkeep | Internal compliance or security staff | Recurring | How often the System Security Plan changes. Where a change introduces a risk the SSP does not address, the SSP update and related records add effort |
| Evidence upkeep and retention | Internal administrators or a platform support provider | Recurring | Log volume, retention settings and whether impact analyses are linked to change records automatically or by hand |
| External review of the process | Independent consultant or implementation partner, if engaged | One-time or periodic | Scope of review and whether it covers a sample of changes or the full process. Confirm scope and deliverables in writing before work starts |
| Assessor sampling during assessment | Independent assessor or certification body, paid by the organization | Periodic, tied to assessment cycle | Number of changes the assessor samples and how quickly complete, final records can be produced. Ask the assessor for its sampling approach in advance |
Who owns the analysis, who prepares evidence, and who assesses it
The organization owns the security impact analysis and the decision to implement a change. The change board sets the rule for which changes must be analyzed, decides whether each change is significant, and records the outcome before work begins. An assessor will look for proof that the analysis happened first, so the board's records must show the sequence, not a reconstruction written after the fact.
- Scope of review: Define which changes go through the analysis, including emergency changes, and write the rule into the change management procedure.
- Significance test: Decide whether a change is significant. The DoW FAQ notes that a new risk not addressed in the existing SSP probably indicates a significant change, so use the SSP as the reference point.
- Approval record: Capture who approved the change, when, and against which version of the analysis.
- Deferrals and rejections: Keep minutes showing that the board sometimes deferred or rejected changes, because records that only show approvals suggest the gate is not working.
Check that the board charter names the analysis as a required gate and that its records would hold up if an assessor sampled recent changes.
System owners describe each proposed change in operational terms, and the security team judges what it does to the protections documented in the system security plan. Together they produce the analysis that the change board reviews. Level 2 covers 110 requirements, so a change to one component can touch access control, audit logging, boundary settings or encryption without anyone noticing unless the analysis asks the question.
- Change description: Record the affected components, configuration items, data flows, accounts and any CUI handled by the system.
- Control impact: Identify which SSP sections and requirements the change could affect, including access control, audit logging and boundary protection.
- Tool outputs: Attach scan results, configuration comparisons or test results that support the conclusion.
- Documentation update: If the change introduces a risk the SSP does not address, update the SSP before the change goes live.
Check that security can name the SSP sections a sample of recent changes affected and that each SSP update carries a date earlier than the implementation date.
An implementation partner such as DeployOpen designs the analysis workflow, configures the tooling that holds the records, and assembles the evidence an assessor will request. The partner prepares the system and the paperwork. It does not decide whether a change is significant, approve changes, or declare CM.L2-3.4.4 met. Those decisions remain with the organization, and the conclusion belongs to the assessor.
- Workflow design: Write the analysis template, the triggers and the approval routes so they match the organization's SSP and change procedure.
- Ticketing configuration: Set up change request types in a tool such as GLPI, whose Assistance module follows ITIL practices, so each change carries its analysis fields.
- Evidence assembly: Organize change records, analysis documents, tool outputs and audit log extracts by change and by date.
- Gap testing: Run a sample of past changes through the new workflow to find where records are missing or dated in the wrong order.
- Handover: Train the change board and system owners, and document who maintains the workflow after delivery.
Check that the written scope lists these deliverables and states that approvals and assessment conclusions stay with the organization and its assessor.
Assessors test CM.L2-3.4.4 against its single assessment objective in NIST SP 800-171A: the security impact of changes is analyzed before they are implemented. They may also test the organization's analysis process itself, which means sampling changes and asking for the records. Level 2 certification assessments are performed by C3PAOs authorized or accredited by The Cyber AB. On 13 July 2026 the Department of War suspended CMMC Phase II, so confirm which assessment type a given contract requires.
- Independent testing: The assessor selects changes and checks that the analysis predates implementation.
- Final evidence: A requirement is met only with evidence in final form, so finalize analyses and approvals before the assessment begins.
- Independence line: A partner may prepare evidence and run practice reviews, but it cannot score the requirement or issue a report or certificate.
- Scoring context: CM.L2-3.4.4 is worth 1 point, but its status can still matter for contract eligibility, so confirm how a gap would be handled under the contract.
- Assessor selection: Confirm the C3PAO's authorization or accreditation through The Cyber AB and ask how it handles conflicts of interest with the partner.
Check that the assessor has told you which sample of changes they will request and that your records can answer that sample without rework.
Where security impact analysis evidence usually falls short
Assessors test CM.L2-3.4.4 by checking whether the analysis happened before the change, whether it is tied to the change record, and whether it reflects the system as documented. The gaps below break one or more of those links, and each has a fix that can be built into the change process before the next assessment.
Analyses written after deployment
The most common failure is a security impact analysis completed during or after the change window, often to satisfy a ticket that was closed on deployment. The requirement is that the analysis happens before the change is implemented, so an analysis dated after the fact shows the process did not work. Fix: make a completed, reviewed analysis a required field that blocks the change from moving to the implementation state. Check that timestamps on the analysis precede the implementation timestamp in the change record.
Change tickets without analysis links
Many organizations run a change board in one tool and keep security analyses in documents on a shared drive, so nothing connects the two. An assessor who picks a change record cannot find its analysis, and the organization cannot show that every significant change was reviewed. Fix: give each change record a unique identifier, store the analysis as an attachment or linked item on that record, and run a periodic query for approved changes with no linked analysis. Ticketing platforms such as GLPI's Assistance module, which follows ITIL-style tickets and changes, can hold this link if it is configured to require it.
Generic templates that ignore the SSP
A template that asks only whether the change is "low risk" does not show the system security plan was considered. Analyses should name the affected components, the security requirements they support, and whether the change alters any control described in the SSP. Fix: build the template around the SSP's system boundary and control list, so each analysis records which controls the change touches. The DoW CMMC FAQ notes that a new risk not addressed in the existing SSP probably signals a significant change, so the template should force that comparison.
Missing reviewer sign-off
An analysis written and approved by the same engineer who made the change gives assessors little confidence that the risk was reviewed. Evidence should show a reviewer with security responsibility who was not the implementer, and the date of that review. Fix: set the approval rule so the change requester cannot approve their own analysis, and require a named security reviewer before the change board authorizes implementation. Keep the approval record with the analysis, not in a separate inbox.
Emergency changes with no record
Urgent fixes applied directly to production, often by an administrator during an incident, are the gap assessors probe most. Emergency paths still change the system, so the analysis still applies, even if it is completed after the fix to document the risk. Fix: define an emergency change procedure that creates a ticket at the moment of action, requires a retrospective analysis within a timeframe your organization sets and approves, and flags the record for review. Confirm that your audit logs capture privileged changes made outside the normal path, since those logs are common evidence for this requirement.
How much effort and outside help does 3.4.4 need?
How much extra work does security impact analysis add to change management?
For most changes, it adds a short written review step, not a separate project. The analysis asks one question before a change goes ahead: could this change alter how the system protects CUI? The work scales with how much the change touches. A routine patch to a workstation image usually needs a brief note confirming it does not alter security settings, access paths or boundary controls. A change to firewall rules, identity settings or the system security plan needs a fuller write-up and reviewer sign-off. The effort is recurring, because every change needs the step, so the biggest savings come from defining standard change types that are pre-cleared and only escalating the exceptions.
Can a small team handle security impact analysis without outside help?
Yes, a small team can usually run it in-house if it has a named owner, a short change template and someone who knows the system security plan well enough to spot a significant change. The main risk for small teams is informal changes that never reach the record. Outside help is most useful for the initial setup: defining what counts as significant, building the template and tying the analysis to the SSP and the change log. An implementation partner can prepare these artifacts, but the organization owns the analysis and its decisions, and an independent assessor will test whether the process works in practice.
How long does setting up security impact analysis take?
The setup time depends on scope: how many systems are in the CUI boundary, how many change sources exist, and whether a ticketing or change tool already records changes. No duration has been supplied for this topic, so ask any provider to state the time in a written, fixed scope before work begins. A narrow scope, such as one enclave with an existing change board, is far quicker to set up than a multi-site environment with cloud, endpoint and on-premises changes. Most of the time goes into agreeing the significance criteria with the people who approve changes, not into the tooling itself.
What does the work need from our IT and security staff?
The work needs time from three roles. The change owner must describe each change's security relevance. A security reviewer must decide whether the change is significant and whether the SSP needs updating. A system owner must keep the analysis documentation current. Expect these roles to be recurring, with peak effort during setup. Ask whether your staff will need training on the criteria and whether the change board can absorb the extra review step without creating a backlog that pushes engineers toward unrecorded changes.
Will an assessor test security impact analysis, and what will they ask for?
Yes. Assessors can test the organization's security impact analysis process under NIST SP 800-171A, which lists analysis documentation, change control records and audit records as potential evidence. They will typically sample recent changes and check whether each one was analyzed before implementation and whether the analysis was recorded. A change without a record, or an analysis completed after deployment, will not meet the objective. Draft documents are not final evidence, so the process and its records must be in final form before the assessment. Confirm the assessment method and the evidence expectations in the current CMMC Assessment Guide.
What happens to our Level 2 status if 3.4.4 is still open?
3.4.4 is worth 1 point, and it is not on the exclusion list in 32 CFR 170.21(a)(2)(iii), so it can go on a Plan of Action and Milestones (POA&M) if the score is at least 88 of 110 (0.8). The POA&M must close within 180 days. This allows Conditional Level 2 status. The point is only deferred, not waived, so open items must be closed within the window. Also check the current CMMC phase status, because the Department of War has suspended Phase II, and confirm the current rules with your contracting officer before relying on a POA&M.
Which parts of security impact analysis can we outsource?
Several parts can be outsourced without transferring ownership of the control. An implementation partner can design the change template, configure the change records in your ticketing system, prepare the significance criteria for review and gather evidence for the assessor. DeployOpen prepares systems, controls and evidence for compliance assessments, under a written, fixed scope. DeployOpen does not issue audit reports or certifications. Keep the decision to approve significant changes with your own staff, and confirm with any assessor which evidence they accept before the work begins.
How DeployOpen prepares change and analysis evidence for CMMC
DeployOpen works with the organization to put a security impact analysis step into its change process and to prepare the records an assessor will ask for under CM.L2-3.4.4. The organization owns its controls and decisions, while DeployOpen prepares the systems, procedures and evidence; only an independent assessor can judge whether the requirement is met.
How we scope
- Engagements are fixed-scope, with the systems, change types and deliverables for CM.L2-3.4.4 agreed in writing before work starts.
- We review how changes are raised today and where a security impact analysis would fit before implementation.
- The written scope names which change records, tools and approval routes are in and out of the work.
How we build
- We configure the change workflow so each change request carries a documented security impact analysis before approval.
- We set up a ticketing and change module, such as GLPI's Assistance module, to hold analysis fields, approvals and status.
- We define how a new risk not already covered in the System Security Plan triggers a fuller review of the change.
How we hand over
- We document the analysis procedure, roles and decision criteria in plain language for the organization's own staff.
- We deliver sample change records and audit trails that show analysis completed before implementation, for the organization to review.
- We confirm with the organization and its assessor which evidence forms they will accept and in what final form.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the initial handover.
- We can review the change process when systems, tools or the System Security Plan change materially.
- Questions about how an assessor will test the analysis process should be confirmed with the assessor, not assumed.
