Free Certified in Governance, Risk and Compliance (CGRC) practice test: 30 questions with answers

Implementation means putting the selected control into operation as the plan describes, which is what later assessment verifies. Poems, furniture, and naming are not implementation activities.

The system security and privacy plan records the implementation of each selected control, which is what assessors check against. Invoices, minutes, and holiday schedules do not describe control implementation.

Documented implementation gives assessors a basis for verification and gives decision makers the evidence they need. Pricing, screen colours, and the claim that documents replace testing are not accurate.

A deviation must be documented, its residual risk assessed, and accepted by an authorized decision maker before the system proceeds. Leaving it undocumented, deleting the control, or informing one person hides the risk from those accountable for it.

Configuring the system to the requirement and documenting the evidence are core implementation responsibilities. Deleting logs, sharing root passwords, and disabling monitoring each remove the controls or the records that the implementation is meant to provide.

The organization-wide risk management strategy frames how risk is assessed and tolerated across all systems, including appetite and response approach. The system security plan, plan of action, and assessment report each document a single system or a single activity rather than the enterprise approach.

The authorizing official makes the risk-based authorization decision and accepts residual risk on behalf of the organization. Administrators, engineers, and help desk staff implement or support controls but do not hold that acceptance authority.

Likelihood estimates how probable it is that a threat exploits a vulnerability, which combines with impact to produce risk. Control cost, user counts, and system age do not measure likelihood.

Clear roles for risk decisions and an approved, periodically reviewed policy form the core of a governance structure. Single-person configuration control, deleting policies yearly, and limiting governance to IT each weaken oversight across the organization.

A risk register records each identified risk with an owner, a rating, and its treatment status so that management can oversee it. Budgets, training records, and contract numbers are useful records but do not track risk.

Tailoring starts from a baseline and adjusts it for the mission, environment, and risk, with the rationale recorded. Sewing, labelling, and deleting inconvenient controls are not tailoring.

The impact categorization of information and services determines the baseline that applies as the starting point. Printer models, dashboard colours, and staff heights have no bearing on the required controls.

Systems that process personal information need privacy controls that address collection, use, and handling, alongside security controls. Privacy controls do not replace security controls, and report appearance and login colours are unrelated.

Impact categorization and applicable legal and organizational requirements are the primary inputs for selecting controls. Logos, help desk staffing, and vendor sales material do not determine which controls the system needs.

A security assessment checks whether controls are implemented correctly and operating as intended, which is the evidence for authorization. Budgets, diagrams, and fonts are not the assessment's purpose.

An assessment report records control results and findings with the risk they represent, which supports the authorization decision. Seating plans, logos, and menus are not assessment content.

Examination reviews documents, records, and artifacts to confirm a control is defined and in place, which is one of the standard assessment methods. Printing, pinging, and colouring do not assess a control.

Interviews and testing are standard assessment methods that check how a control operates in practice and what it produces. Painting rooms, deleting reports, and ordering equipment are not assessment methods and erase or avoid evidence.

An authorization decision is a formal acceptance of residual risk by an authorizing official, allowing operation with a stated scope and term. Purchase orders, logos, and rosters are unrelated business records.

A POA&M lists the weaknesses, planned corrective actions, owners, and milestones, which is how outstanding risk is managed. Lunch orders, holidays, and font choices are not part of it.

The authorization package gathers the plan, assessment results, and remediation plan so that the authorizing official can make an informed risk decision. Staff photos, building access lists, and screen colours are not part of it.

The security plan, assessment report, and plan of action and milestones are the core evidence for an authorization decision. Floor plans, vendor brochures, and holiday rotas are not evidence of the system's control posture.

Continuous monitoring keeps control effectiveness and the system's risk posture under review after authorization. Television, one-time audits, and filing printed logs do not sustain that oversight.

Changes that affect security, such as a new interconnection or new data types, may alter the risk and require review. Coffee machines, birthdays, and logo redesigns do not change the system's security posture.

Tracking changes lets the organization assess whether each one alters the authorized state and needs review. Page counts, report colours, and staff reduction are not reasons for change tracking.

Reauthorization renews the decision after a defined period or a significant change, so the risk acceptance stays current. Domain renewals, staff replacement, and repainting are unrelated to authorization.

The boundary establishes which components, connections, and users belong to the system being authorized, which determines what is assessed. Office walls, vendor contract terms, and internet speed are not part of that definition.

The information types and their impact drive the categorization, and the categorization sets the baseline of controls. Interface colours, printed guides, and vendor preference do not determine security requirements.

An interconnection agreement records the data flows, controls, and responsibilities that govern the connection to another system. Lunch schedules, replacing the security plan, and office monitors are not its purpose.

The operational environment shapes the threats, dependencies, and constraints that affect the system's risk and the controls needed. Room colour, licence prices, and departure lists are not part of scope definition.