Assessment And Audit practice questions

Reviewing policies

Why it fails: Policies are subjective interpretations of intent.

Interviewing the IT manager

Why it fails: Interviews are subjective.

Observing physical access

Why it fails: Observation can be subjective depending on duration.

Current state, Target state, Gap identification

Why it fails: This is backwards.

Gap identification, Target state, Current state

Why it fails: You cannot identify a gap without the states.

Current state, Gap identification, Target state

Why it fails: The target must be known for a gap to exist.

Employee performance reviews

Why it fails: Not part of an audit report.

List of all vendor contracts

Why it fails: Irrelevant to control assessment.

Company financial statements

Why it fails: Not part of a security report.

Physical building aesthetics

Why it fails: Irrelevant.

HR hiring policies

Why it fails: These are part of administrative controls, not a distinct category.

Marketing controls

Why it fails: Not a standard security control type.

Prepare an assessment plan and obtain management approval.

Why it fails: An assessment plan is typically part of the initial preparation phase, before procedure development. In NIST SP 800-53A, the plan outlines scope, objectives, and logistics, but the detailed procedures for each control come after. The question states that scope and objectives are already defined, so the next step is procedure development, not plan approval.

Analyze the collected evidence and determine control effectiveness.

Why it fails: Analysis and determination of effectiveness occur after evidence collection. This is a later step in the assessment process. Without first developing procedures and then collecting evidence, there is nothing to analyze. NIST SP 800-53A sequences development of procedures before evidence collection and analysis.

Conduct the assessment by collecting evidence through interviews and observations.

Why it fails: While collecting evidence is a later phase, it follows procedure development. Jumping directly to evidence collection without defined procedures risks inconsistent or incomplete assessment. NIST SP 800-53A emphasizes a structured approach where procedures are designed first to ensure all necessary evidence is gathered and evaluated against clear criteria.

Observing a security guard checking badges at the data center entrance.

Why it fails: Observing a security guard is a form of examination (observation) and can provide evidence of physical access control. However, it is not one of the primary objective evidence gathering methods for logical access control policies in an information system. NIST SP 800-53A focuses on examine, interview, and test; observation is a type of examination but is less relevant to evaluating logical access control policies.

Interviewing system administrators about their access control practices.

Why it fails: Interviewing system administrators is an assessment method, but it yields subjective evidence based on personal knowledge and opinion. While interviews are valuable for understanding processes, they do not provide objective proof of control effectiveness. NIST SP 800-53A classifies interviews as a method that can corroborate other evidence but should not be the sole basis for determining control effectiveness.

Reviewing the organization's security awareness training records.

Why it fails: Reviewing training records is an examination activity that provides evidence of compliance with training requirements, but it does not directly assess the effectiveness of access control policies. While it is objective evidence, it is not specific to access control evaluation. The question asks for methods to evaluate access control policies, and training records are tangential to that objective.

Proceed to Stage 2 audit and address the gaps during the audit.

Why it fails: Proceeding to Stage 2 without complete documentation would undermine the audit's integrity. Stage 2 assesses the implementation and effectiveness of the ISMS, which relies on a complete set of documentation. The certification body should not proceed if critical documentation is missing, as it may lead to an ineffective audit and potentially an unjustified certification. The gaps must be addressed before Stage 2.

Conduct a full Stage 2 audit but exclude the risk treatment process from the scope.

Why it fails: Excluding a critical process like risk treatment from the scope would invalidate the certification. Risk treatment is a core requirement of ISO/IEC 27001, and its exclusion would mean the ISMS does not meet the standard. The certification body cannot arbitrarily exclude required processes; the organization must address the gaps to achieve certification. Scope exclusions are only permissible for non-applicable requirements, not for incomplete implementation.

Cancel the certification process immediately due to the incomplete documentation.

Why it fails: Canceling the certification process is premature. ISO/IEC 27001 allows organizations to address nonconformities and continue the certification process. The certification body should provide the organization with an opportunity to correct the gaps. Immediate cancellation would be disproportionate and not aligned with the standard's approach, which encourages continual improvement and corrective action.

To standardize the transfer of vulnerability data

Why it fails: OVAL assesses machine state against expected configuration, not data transport. Standardising vulnerability data transfer is the role of the CVE and CVSS naming and scoring conventions within SCAP. It is tempting because SCAP does exchange vulnerability information between scanners and repositories, but that interoperability function belongs to those other components, not OVAL's assessment definitions.

To define the severity of a vulnerability

Why it fails: Severity scoring is CVSS's function, which assigns base, temporal and environmental metrics to vulnerabilities. OVAL instead expresses machine-readable state checks used to evaluate whether a system conforms to a defined configuration. It is tempting because OVAL results often accompany severity data in scan reports, but OVAL itself carries no scoring scale or severity semantics.

To manage the lifecycle of a POA&M

Why it fails: POA&M lifecycle management is a governance workflow performed in GRC tooling, not a SCAP specification. OVAL defines structured, machine-readable checks that compare a system's actual state against expected configuration. It is tempting because assessment findings do feed POA&M entries, but OVAL supplies the technical check content, not the remediation tracking process itself.

Analyze Security Assessment Results

Why it fails: Analysing results happens after assessment evidence is collected, not directly after preparation. It is tempting because analysis is a real assessment activity, yet the phase immediately following preparation is conducting the assessment itself; analysis only begins once that data exists.

Develop the Plan of Action and Milestones (POA&M)

Why it fails: The POA&M is developed after assessment findings are analysed and documented, so it cannot immediately follow preparation. It is tempting because remediation planning is part of the wider process, but the next step is conducting the assessment to gather the evidence a POA&M would address.

Authorize the Information System

Why it fails: Authorising the information system follows the Assess, Document Results and Report phases, not Prepare. It is tempting because authorisation is the assessment's ultimate purpose, and it would be the next step once controls are assessed and residual risk accepted by the authorising official.

Interconnection Security Agreement

Why it fails: An Interconnection Security Agreement governs the security requirements for connecting two organisations' IT systems, typically for data exchange between networks. It does not set out audit scope, objectives or the assessor's authorised boundaries. It is tempting because it is a formal agreement, but it would be correct when two parties interconnect systems, not when scoping an assessment.

Security Assessment Plan

Why it fails: A Security Assessment Plan details the assessment's scope, methodology, schedule and rules of engagement, but the primary agreement establishing that scope between assessor and organisation is the authorisation-to-operate documentation or contract. It is tempting because it is assessment-specific, yet it operationalises the agreed scope rather than constituting the governing agreement itself.

Risk Assessment Report

Why it fails: A Risk Assessment Report documents identified threats, vulnerabilities and their likelihood and impact; it does not define the agreed scope, boundaries or rules of engagement between assessor and organisation. It is tempting because assessments begin with risk analysis, but it would be the correct artefact after testing, not the agreement establishing what will be audited.

System Security Plan

Why it fails: A System Security Plan describes the system's controls, boundaries and environment, serving as the organisation's own control documentation. It does not constitute the agreement between assessor and organisation defining audit scope. It is tempting because it delineates system boundaries, but it would be correct as the control baseline an assessment examines, not the scoping agreement.

Privacy policy publication

Why it fails: Publishing a privacy policy addresses notice and choice under the Privacy criterion; it provides no evidence of system uptime, performance monitoring or disaster recovery. It is tempting because privacy documentation is frequently requested in SOC 2 audits, but it maps to Privacy, not Availability.

Encryption of data at rest

Why it fails: Encryption at rest protects confidentiality of stored data; it does nothing to demonstrate uptime, capacity or recoverability, which the Availability criterion measures. It is tempting because encryption is a common SOC 2 control, but it belongs under the Security (Common Criteria) category, not Availability.

User access review logs

Why it fails: User access review logs evidence logical access controls, which map to the Security criterion, not Availability. Availability evidence covers uptime, capacity, backup, recovery and incident handling; access reviews would be the right artefact when demonstrating Security criteria compliance.

Immediately terminate the cloud service

Why it fails: Terminating the service removes the environment rather than tracking the control deficiency, and FedRAMP expects remediation, not shutdown. It is tempting as an aggressive risk response, but the mandatory next step is recording the gap in the POA&M so remediation is monitored to closure.

Perform a penetration test

Why it fails: Penetration testing probes exploitable weaknesses; it does not record a control gap in the FedRAMP continuous-monitoring workflow. It is tempting because testing evidences control effectiveness, but the mandatory next step is documenting the finding in the Plan of Action and Milestones (POA&M) so remediation is tracked.

Request a waiver from the JAB

Why it fails: A JAB waiver is a formal authorisation decision for an accepted deviation, not the tracking mechanism for a newly found gap. Requesting one is tempting because waivers address unmet controls, but the mandatory next step is entering the finding into the POA&M with milestones, owners and dates.

Update the System Security Plan (SSP) to reflect compliance

Why it fails: Editing the SSP to claim compliance falsifies the authorisation package; the SSP documents the implemented control baseline, not open findings. Updating it is tempting because SSPs describe controls, but the mandatory next step is logging the deficiency in the POA&M for tracked remediation.

Running a Nessus vulnerability scan

Why it fails: A Nessus scan enumerates software vulnerabilities and missing patches; it does not report which users hold which permissions, so it cannot verify least privilege. It is tempting because scanning is a core audit technique, and it would be correct when the objective is identifying unpatched services or configuration weaknesses on the host.

Checking for physical server room access

Why it fails: Physical server room access concerns facility controls, not the permissions granted to Linux accounts, so it cannot evidence least privilege. It is tempting because auditors do assess physical safeguards, and it would be correct where the scope covers data-centre access controls rather than operating system authorisation.

Reviewing system logs for failed login attempts

Why it fails: Failed login attempts show authentication errors, not the permissions assigned to accounts that successfully authenticate, so they cannot demonstrate least privilege. It is tempting because logs are an audit staple, and reviewing them would be correct when investigating brute-force attempts or unauthorised access attempts against the server.

POA&M is prohibited for cloud providers

Why it fails: POA&Ms remain permitted; cloud providers simply cannot remediate customer-side findings, so responsibility for inherited controls shifts to the provider's own remediation processes. It is tempting because provider findings are handled internally, and prohibiting POA&Ms would be correct only if no remediation tracking were ever allowed.

Physical security is no longer assessed

Why it fails: Physical security controls still exist in cloud-native environments; they transfer to the provider as inherited controls rather than disappearing from assessment scope. It is tempting because customers no longer implement physical safeguards themselves, and this would be correct only if providers offered no physical controls at all, which they plainly do.

Manual testing is mandated for all controls

Why it fails: Manual testing is not mandated for every control; inherited controls are typically assessed through provider attestations, certifications and continuous monitoring evidence instead. It is tempting because manual verification feels rigorous, and it would be correct when controls cannot be evidenced any other way, not as a blanket cloud requirement.

Third-party assessment

Why it fails: A third-party assessment is conducted by an external independent party, contradicting the stem's internal department performing the review. It is tempting because it also evaluates security control effectiveness, and would be correct where independent external assurance or vendor attestation is required rather than self-assessment.

Penetration test

Why it fails: A penetration test actively exploits vulnerabilities to validate resistance, not to assess control effectiveness through internal review. It is tempting because it examines security controls, and would be correct when the objective is demonstrating exploitable weaknesses or testing detection and response under simulated attack.

Regulatory inspection

Why it fails: A regulatory inspection is driven by an external regulator's compliance mandate, not a voluntary internal department review free of external pressure. It is tempting because it also examines security controls, and would be correct when assessing conformity against statutory or regulatory requirements imposed by an authority.

Delete the finding from the report

Why it fails: Deleting a High finding removes it from the assessment record, so no POA&M entry, milestone or remediation evidence can be tracked. Findings must be documented with remediation plans and completion dates. Deletion is tempting when a finding is disputed or already fixed, but that requires a formal appeal or closure process, not erasure.

Transfer the risk to the IT staff

Why it fails: Risk transfer moves financial liability via insurance or contracts; it does not remove the system owner's accountability for documenting the High finding and its remediation in the POA&M. IT staff cannot absorb authorisation responsibility. Transfer is tempting where a vendor or insurer covers losses, but the POA&M entry remains.

Accept the risk without documentation

Why it fails: Risk acceptance still requires documented authorisation, usually by a senior official, with the finding recorded in the POA&M and reviewed periodically. Undocumented acceptance leaves no accountability or audit trail. It is tempting when remediation cost outweighs impact, but that judgement must be written down and approved.

NIST SP 800-37

Why it fails: NIST SP 800-37 provides the Risk Management Framework for authorising and continuously monitoring systems, not the audit programme structure. It is tempting because it is a widely used NIST publication covering security lifecycle governance, and would be the right choice when the task is system authorisation rather than audit conduct.

PCI DSS

Why it fails: PCI DSS is a payment card data security standard containing prescriptive controls, not a framework for planning and conducting information security audits. It is tempting because it mandates audits for compliance, and would be the right choice when the requirement is securing cardholder data environments.

ISO/IEC 27001

Why it fails: ISO/IEC 27001 specifies requirements for an information security management system and its certification, not the procedural framework for conducting audits. It is tempting because it is the flagship information security standard, and would be the right choice when the objective is establishing or certifying an ISMS.

Audit log retention

Why it fails: Audit log retention preserves records of activity; it does not enforce account lifecycle. Disabling inactive accounts requires an access-review or provisioning control that detects dormancy and revokes entitlements. Retention is tempting because auditors rely on logs to evidence who did what, and it would be the right control when the requirement is preserving evidence for a defined period.

Role-based access control

Why it fails: Role-based access control governs which permissions an identity holds while active; it does not detect or disable dormant accounts. It tempts because RBAC is central to IAM authorisation, and it would be correct if the audit finding concerned excessive or misassigned entitlements rather than accounts left enabled after inactivity.

Multi-factor authentication

Why it fails: Multi-factor authentication verifies identity at sign-in; it does not monitor account dormancy or revoke access after inactivity. It tempts because MFA is a core IAM access control, and it would be the right answer if the finding concerned weak authentication or credential compromise rather than stale accounts.

To terminate the contract

Why it fails: Reporting produces the assessment report and supports authorisation decisions; contract termination is a programme or procurement action unrelated to communicating control assessment outcomes. Termination would be relevant only if a vendor failed contractual security obligations during performance.

To select new security controls

Why it fails: Assessment Reporting documents and communicates findings, risk, and recommendations to stakeholders; it does not select controls, which happens during control selection earlier in the RMF process. Selecting controls is the correct activity when defining a system's initial control baseline before assessment begins.

To patch all identified vulnerabilities

Why it fails: Reporting conveys assessment results and residual risk to authorising officials; remediation of vulnerabilities occurs in the subsequent remediation and monitoring steps, not during reporting. Patching would be correct once findings are approved and a remediation plan is executed.

Manufacturer's technical specification document

Why it fails: A manufacturer's technical specification describes claimed capabilities, not independent validation against FIPS 140-3 requirements. It is tempting because specifications detail cryptographic algorithms and key lengths, but only a CMVP certificate confirms the module passed accredited testing and appears on the NIST validated list.

Internal configuration audit report

Why it fails: An internal configuration audit report documents the organisation's own settings, not independent cryptographic module testing against FIPS 140-3. It is tempting because audits evidence internal compliance posture, but FIPS validation demands a CMVP-issued certificate confirming the module passed accredited laboratory testing.

Email from the vendor

Why it fails: An email from the vendor is unverified assertion, carrying no cryptographic module validation certificate or CMVP reference. It is tempting as quick confirmation, but FIPS 140-3 validation requires the module's certificate number listed on the NIST CMVP validated modules list.