Study guide
5.4 Preparing the Initial Assessment/Audit Report
ISC2 Certified in Governance, Risk and Compliance CGRC
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
0.1 ISC2 CGRC Exam Structure, Logistics & Passing Strategy 0.2 NIST RMF 7-Step Lifecycle & GRC Architecture
2 Chapter 1: Security and Privacy Governance, Risk Management, and Compliance Program
1.1 Enterprise Governance & GRC Frameworks 1.2 Security and Privacy Objectives: CIA, Non-Repudiation and Privacy Concepts 1.3 Multi-Tier Risk Management & Assessment Methodologies 1.4 System Development Life Cycle and Information Life Cycle Management 1.5 Establishing and Operating the Compliance Program 1.6 Legal, Regulatory & Federal Compliance Drivers 1.7 Privacy Governance, Organizational Roles & ISC2 Code of Ethics
3 Chapter 2: Scope of the System
2.1 System Boundary Definition, Architectural Context & Types 2.2 Identifying Information Types with NIST SP 800-60 2.3 System Categorization Process & Impact Analysis (FIPS 199 / SP 800-60) 2.4 Impact and Risk Determination Under Non-Federal Frameworks 2.5 System Registration, Environment & Interconnection Agreements
4 Chapter 3: Selection and Approval of Framework, Security, and Privacy Controls
3.1 Control Catalogs & NIST SP 800-53 Rev. 5 Structure 3.2 Control Allocation & Inheritance Models 3.3 Control Tailoring, Scoping & Overlay Guidance 3.4 Data Handling and Marking Requirements 3.5 Documenting Control Selection and Securing Stakeholder Agreement 3.6 Continuous Monitoring Strategy & Control Selection Approval
5 Chapter 4: Implementation of Security and Privacy Controls
4.1 Developing the Implementation Strategy: Resourcing, Funding and Timeline 4.2 Identifying Control Types: Management, Operational, Technical and Functional Classes 4.3 System Security and Privacy Plan (SSP/SSPP) Development 4.4 Security Engineering Principles & Technical Control Implementation 4.5 Secure Baseline Configuration & System Hardening 4.6 Implementing Compensating and Alternate Controls 4.7 DevSecOps, SDLC Integration & Supply Chain Risk Management 4.8 Documenting Control Implementation: Policies, Procedures, Plans and Risk Registers
6 Chapter 5: Assessment/Audit of Security and Privacy Controls
5.1 Security Assessment Plan (SAP) & Assessor Independence 5.2 Assessment Methods, Objects & Depth/Coverage 5.3 Assessment Execution, Vulnerability Scanning & Testing 5.4 Preparing the Initial Assessment/Audit Report 5.5 Selecting Risk Responses: Avoid, Accept, Share, Mitigate, Transfer 5.6 Stakeholder Collaboration, Corrective Action and Reassessment 5.7 Security Assessment Report (SAR) & Risk Findings Analysis 5.8 Developing the Risk Response Plan: Prioritization and Resources
7 Chapter 6: System Compliance and Authorization
6.1 The Core Authorization Package & Supporting Artifacts 6.2 Plan of Action and Milestones (POA&M) Architecture & Management 6.3 System Risk Acceptance Criteria and Stakeholder Concurrence 6.4 Authorization Decision Process & Decision Types 6.5 Residual Risk Acceptance, Terms of Authorization & Continuous ATO 6.6 Documenting and Communicating the Compliance Decision
8 Chapter 7: Compliance Maintenance and Continuous Monitoring
7.1 Continuous Monitoring Strategy & Operations (NIST SP 800-137) 7.2 Configuration Management & Security Impact Analysis (NIST SP 800-128) 7.3 Incident Response and Contingency Activities in Sustained Compliance 7.4 Awareness, Training, Evidence Collection and Monitoring-Strategy Revision 7.5 Ongoing Remediation, POA&M Sustainment & Annual Reviews 7.6 Event-Driven Reauthorization & System Decommissioning
5.4 Preparing the Initial Assessment/Audit Report
Key Takeaways Explain This Topic AI
SP 800-53A resolves every assessment objective to one of exactly two determinations: satisfied or other than satisfied.
The initial report exists to give the system owner a formal opportunity to respond before findings are finalized, which is a due-process requirement rather than a courtesy.
Assessors report findings and risk analysis; they do not decide remediation or accept risk, and an assessor who dictates fixes has compromised their independence.
Preliminary findings must state the evidence examined and the specific deviation observed, because a finding without evidence cannot survive challenge.
Risk mitigation summaries in the initial report describe options and their effect, leaving the selection of a response to the system owner and Authorizing Official.
Last updated: August 2026
Preparing the Initial Assessment/Audit Report
Task 5.3 sits between conducting the assessment (5.2) and reviewing it to plan risk responses (5.4). Its outputs are specific: risks identified during the assessment, risk mitigation summaries, and preliminary findings recorded. This is the draft report — deliberately not the final one — and understanding why the draft stage exists is what the exam tests.
1. The Two-Value Determination Model
NIST SP 800-53A Rev. 5 structures assessment around determination statements . Each control decomposes into assessment objectives, each objective into determination statements, and each statement resolves to exactly two possible values:
Determination Meaning
Satisfied The evidence shows the objective is met: implemented correctly, operating as intended, producing the desired outcome
Other Than Satisfied Anything else — not implemented, partially implemented, implemented incorrectly, or not demonstrable from available evidence
There is deliberately no "partially satisfied" value. A control that works for 90% of servers is other than satisfied , with the scope of the deficiency described in the finding narrative. Exam distractors regularly offer "partially satisfied" or "compliant with exceptions" as options; both are wrong.
"Other than satisfied" is not a synonym for "failed." It also covers the case where the assessor could not obtain sufficient evidence. If the organization cannot produce logs demonstrating that quarterly account reviews occurred, the objective is other than satisfied even if the reviews genuinely happened — because in assessment terms, an activity that cannot be evidenced did not occur . This is one of the most practically important ideas in Domain 5.
2. What a Defensible Preliminary Finding Contains
Findings are challenged. A finding that cannot survive a system owner's objection wastes everyone's time and damages the assessor's credibility. Each preliminary finding should record:
- Element Content
- Control and objective The specific control and determination statement not met
- Assessment method used Examine, interview, or test — and against which assessment object
Evidence examined Named artifacts, configuration exports, screenshots, interview records, scan output with dates
- Observed condition Precisely what was found, in factual terms
- Required condition What the control and its organization-defined parameters require
- The deviation The gap between observed and required
- Preliminary risk analysis Likelihood, impact, and affected scope in context
The discipline that separates strong findings from weak ones is separating observation from conclusion . "Account lockout is misconfigured" is a conclusion. "The Corporate-Auth-Baseline policy exported 2026-08-14 sets lockoutThreshold to 10; the SSP-approved organization-defined parameter is 5; 340 of 1,200 directory objects inherit this policy" is an observation — and it is far harder to dispute.
Contextualized Risk, Not Raw Severity
The initial report gives risk ratings, not just technical severity. A CVSS base score describes intrinsic severity in the abstract; the assessment must place it in this environment. Applying NIST SP 800-30 Rev. 1 , the assessor considers threat sources and events, vulnerability severity, predisposing conditions , existing controls, likelihood of occurrence, and impact — which is how the same 9.8 CVSS vulnerability can rate High on an internet-facing portal and Low on an air-gapped lab host with no sensitive data.
Important
Critical findings do not wait for the report. Rules of Engagement require immediate escalation of actively exploitable, high-impact conditions — typically within hours — to the ISSM, system owner, and Authorizing Official. Holding an unauthenticated remote-code-execution finding on a production system for three weeks until the draft report circulates is an assessor failure, not thoroughness.
3. Why the Draft Stage Exists
The initial report is issued to the system owner before findings are finalized, and this serves four purposes:
Factual accuracy. Assessors work with incomplete context. A finding may rest on a misunderstanding of the architecture, on evidence the assessor was not given, or on testing a decommissioned component. The response window catches these cheaply.
Due process. The system owner has a legitimate right to respond before findings become part of the permanent authorization record and drive an AO decision.
Early remediation. Simple deficiencies — a misconfigured parameter, a missing procedure document — can often be fixed within the response window and reassessed , so they never reach the final report as open items. This is the mechanism task 5.4 refers to as reassessing non-compliant findings with newly applied corrective actions.
Risk response planning. The system owner needs the findings in hand to plan responses, which is exactly what task 5.4 requires.
Legitimate Versus Illegitimate Challenges
- Legitimate Illegitimate
- Factual error — the assessor tested the wrong host "This finding will delay our authorization"
- Evidence exists but was not provided during fieldwork "No other system gets cited for this"
- The finding misreads a documented compensating control "The risk rating makes us look bad to leadership"
- The organization-defined parameter cited is out of date "Our budget cannot cover remediation"
An assessor revises findings for the left column and holds firm on the right. Adjusting a risk rating because a stakeholder finds it politically inconvenient is a loss of independence , and independence is what gives the report its value to the Authorizing Official.
4. Risk Mitigation Summaries: Describe, Do Not Decide
The blueprint asks for "risk mitigation summaries outlined" in the initial report, and candidates consistently over-read this. The assessor may describe options and their likely effect on risk. The assessor may not select the response, commit the organization to a remediation, set a completion date, or accept risk on anyone's behalf.
The reason is structural. An assessor who designs the fix is later assessing their own work, which destroys the independence the whole model rests on. If the assessor specifies "implement a jump-host architecture with session recording," then reassesses that architecture, there is no independent evaluation left — the same conflict of interest that bars the ISSO from assessing the controls they operate.
The correct boundary:
Assessor Says Assessor Does Not Say
"This deficiency could be addressed by enforcing the parameter through group policy, by network isolation, or by a compensating control; each would reduce likelihood." "You will implement group policy enforcement by 30 September."
"Residual risk after correction would be Low." "This residual risk is acceptable."
"Three findings share a root cause in the change management process." "Reorganize change management under the CISO."
Deciding the response is the system owner's job (task 5.4); accepting the residual risk is the Authorizing Official's (Domain 6).
From Initial to Final
The path is: initial report issued → system owner reviews and responds → factual corrections applied → quick-win remediations completed and reassessed and validated → risk responses selected → final report (task 5.5) records the definitive determination for every objective, incorporating both corrected findings and the results of any reassessment. Findings still open at that point flow to the POA&M and into the authorization package.