GRC Program practice questions

Rename all internal controls to match the NIST sub-category names.

Why it fails: Renaming controls destroys their original identifiers and creates no traceable mapping between NIST sub-categories and internal controls; a GRC tool links them through a mapping or crosswalk relationship. Renaming would be correct only if the organisation wanted control names to mirror framework terminology, not to manage relationships.

Create separate GRC instances for every framework adopted.

Why it fails: Separate instances fragment the control library, so one internal control cannot be linked to sub-categories across frameworks, duplicating evidence and breaking Defence-in-Depth coverage reporting. Separate instances suit wholly segregated business units or regulatory tenants, not a single mapping exercise within one GRC tool.

Hard-code the NIST framework into the GRC platform source code.

Why it fails: Hard-coding fixes the sub-category set at build time, so CSF updates or added frameworks require code changes and redeployment, and controls cannot be re-mapped by GRC administrators. Hard-coding suits a static, single-standard checklist that will never be revised or mapped to other frameworks.

Avoid the risk by discontinuing the business activity that creates the risk.

Why it fails: While risk avoidance is a treatment option, it is often impractical for regulatory compliance risks because the activity may be core to the business. Discontinuing a business line to avoid a compliance risk could be too drastic and may not be feasible. The question asks for appropriate actions for a risk that exceeds appetite; avoidance is possible but not always appropriate, especially if the activity is essential. In this context, mitigation and transfer are more common and practical.

Monitor the risk and reassess it quarterly without taking immediate action.

Why it fails: Monitoring alone is not a treatment option when a risk exceeds appetite. It is part of ongoing risk management but does not reduce or transfer the risk. For a low-appetite regulatory risk, immediate action is required to bring it within appetite. Simply monitoring would leave the organization exposed to potential compliance violations.

Accept the risk without further action because it is within the organization's risk tolerance.

Why it fails: The scenario states the risk exceeds the risk appetite, so acceptance without action is not appropriate. Risk acceptance is only valid when the risk is within appetite or tolerance. For a low-appetite regulatory risk, acceptance would likely violate policy and could lead to compliance breaches.

The number of tickets opened in the GRC helpdesk.

Why it fails: Ticket volume measures helpdesk workload, not GRC's contribution to business objectives, so it says nothing about risk reduction or goal alignment to a Board. It is tempting because operational metrics are easy to collect, and would suit managing support capacity rather than demonstrating strategic value.

The total storage space consumed by evidence files.

Why it fails: Storage consumed by evidence files measures repository volume, not GRC's contribution to business goals, so it fails to demonstrate value to a Board. It is tempting because it is simple to report, and would suit capacity planning or cost management of the GRC platform rather than strategic alignment.

The number of users logged into the GRC platform daily.

Why it fails: Daily logins count platform activity, not outcomes tied to business goals, so they cannot evidence GRC's value to a Board. It is tempting because usage statistics are readily available, and would suit adoption or licence-utilisation reporting rather than demonstrating alignment with strategic objectives.

Disabling the record deletion permission for all users.

Why it fails: Disabling deletion permissions only blocks removal through the platform's own interface; it leaves records mutable, so edits and overwrites still occur, and administrators can re-enable the permission. It is tempting because permission restriction genuinely supports retention and access control, and would suit scenarios demanding least privilege or preventing accidental deletion, but it cannot deliver cryptographic immutability.

Setting the record visibility to 'Public'.

Why it fails: Public visibility only widens who can read a record; it grants no write protection, so evidence remains editable and deletable. Visibility settings suit sharing records across teams, not enforcing immutability for a three-year retention requirement.

Setting the 'Draft' workflow state to permanent.

Why it fails: A permanent Draft state merely fixes the workflow stage; records stay editable and deletable, so immutability is not achieved. Permanent draft states suit evidence still being authored, not retention-locked assessment evidence held for three years.

Configure a global Business Rule to auto-close all findings.

Why it fails: This bypasses the CISO approval requirement.

Change the default notification email template for findings.

Why it fails: Notifications only inform users, they do not enforce workflow logic.

Modify the User Permission set for the CISO account.

Why it fails: Permissions control access, not the automated movement of task states.

Create manual spreadsheets to reconcile the data outside the GRC platform.

Why it fails: Spreadsheets sit outside the GRC platform, so they cannot maintain live relationships between Risk Register entries and Control library objects, which is what CCF mapping requires. It is tempting as a quick reconciliation fix, and would suit one-off reporting where no ongoing linkage is needed.

Force all business units to use identical risk taxonomy naming conventions.

Why it fails: Forcing identical taxonomy naming conventions standardises terminology but does not map controls to risks across frameworks, which is what CCF requires. It is tempting because consistent naming aids comparison, yet CCF mapping depends on relating controls to common objectives, not merely aligning labels across business units.

Disable the Regulatory Requirement module to focus only on Risks.

Why it fails: Removing the Regulatory Requirement module severs the link between obligations and controls, so CCF mapping cannot trace regulations to shared controls. It is tempting when scoping a pilot to reduce noise, and would suit a risk-only register with no compliance obligations to map.

Setting all user passwords to match the local language.

Why it fails: Password language has no bearing on where GRC data is stored or processed, so it cannot satisfy residency requirements. It is tempting because password policies are a familiar access-control setting, and would be relevant to authentication strength or localisation, but residency demands data-location controls such as regional tenancy or storage boundaries.

Encrypting the entire GRC database with one key.

Why it fails: A single encryption key applied across the whole GRC database does not restrict where data is stored or processed, so it cannot satisfy residency requirements. It is tempting because encryption is a common compliance control, and it would be correct if the requirement were protecting data confidentiality rather than controlling its geographic location.

Conducting a system-wide vulnerability scan.

Why it fails: A vulnerability scan identifies software weaknesses; it neither stores data in a region nor enforces residency, which requires configuring data-centre or region placement of GRC repositories. It is tempting because scans are a common GRC control, but residency is a data-location setting, not a security assessment.

Update the manual risk assessment survey annually.

Why it fails: An annual manual survey leaves control effectiveness stale for the rest of the year, so audit results never reach the residual risk calculation. It is tempting because surveys capture assessor judgement, but the fix requires automated, event-driven updates from audit findings.

Increase the frequency of full organizational risk assessments.

Why it fails: Increasing assessment frequency does not connect audit findings to the control effectiveness score, so residual risk stays stale between cycles. It is tempting because regular reassessment improves governance generally, but the fix must feed audit results into the scoring calculation itself.

Require the CISO to manually approve all risk score changes.

Why it fails: Manual CISO approval adds a human gate but does not update the control effectiveness score from audit data, so residual risk remains wrong. It is tempting because approval enforces accountability, but the required fix is automated ingestion of audit results into the scoring model.

Assign Global Administrator rights to the lead auditor.

Why it fails: Global Administrator rights give the lead auditor unrestricted control over the directory, the opposite of least privilege. It is tempting because it guarantees the auditor can reach every resource without access denials, which suits a break-glass administrative account rather than routine audit work.

Enable Single Sign-On (SSO) for all users globally.

Why it fails: Global SSO authenticates users but grants no role scoping, so auditors could retain broad access beyond their duties. It is tempting because SSO reduces password sprawl and sign-in friction, which suits organisations prioritising authentication convenience rather than least-privilege authorisation.

Configure a shared service account for all audit activities.

Why it fails: A shared service account removes individual attribution and typically accumulates broad permissions, preventing least-privilege enforcement per auditor. It is tempting because it simplifies provisioning and avoids managing separate credentials, which suits automated batch processes rather than human audit activities requiring accountability.

The system audit log.

Why it fails: An audit log records discrete system events for traceability and forensic review; it does not aggregate or visualise risk posture. It is tempting because logs underpin assurance evidence, but executives need the reporting dashboard that rolls up control status and risk indicators in real time.

The User Provisioning interface.

Why it fails: User provisioning manages identity lifecycle and access rights, producing no aggregated risk metrics for leadership. It is tempting because provisioning data feeds entitlement reviews, yet real-time risk posture requires the reporting and dashboard layer that consolidates findings, controls and KRIs across the platform.

The API integration module.

Why it fails: API integration moves data between systems but performs no risk aggregation, scoring or presentation itself. It is tempting because real-time posture depends on timely feeds, yet the dashboard and reporting component is what transforms integrated data into executive-facing risk metrics.

To allow every department to have its own data repository.

Why it fails: A System of Record consolidates authoritative data into one governed source; permitting each department its own repository creates the conflicting, duplicated records the concept exists to eliminate. It tempts because departmental autonomy over data feels efficient, but that is the federated model a System of Record deliberately replaces.

To minimize the cost of software licenses.

Why it fails: A System of Record defines the authoritative source for data and its governance, not procurement economics; licence savings are a possible by-product of consolidation, never the primary purpose. It tempts because consolidating repositories can reduce duplicate tooling costs, but cost is not why the structure is defined.

To make the GRC platform run faster.

Why it fails: A System of Record establishes data authority, ownership and traceability; platform performance is an infrastructure concern unrelated to which repository is designated authoritative. It tempts because consolidation can reduce query sprawl, but speed is a side effect, not the defining purpose of the structure.

Requiring the Risk Owner to sign a hard copy document.

Why it fails: A signed hard copy creates a static record with no expiry tracking or automated notification, so reviews still depend on manual chasing. The requirement is automatic review before expiry, which needs date-driven workflow triggers. Hard-copy sign-off suits formal attestation where an auditable wet signature is mandated.

Disallowing all risk exceptions in the system configuration.

Why it fails: Disallowing exceptions removes the temporary-risk mechanism entirely, so nothing remains to review before expiry. The requirement is automated review of expiring exceptions, which needs expiry dates and workflow-triggered notifications. A blanket prohibition would be chosen only where policy forbids any deviation from the baseline.

Setting a manual reminder on the CISO's calendar.

Why it fails: A calendar reminder depends on one person remembering to act and creates no auditable, automatic trigger tied to the exception record. The requirement is automated review before expiry, which needs workflow-driven notifications and escalation. Manual reminders suit small, low-volume processes lacking GRC workflow automation.

The IT Operations Manager.

Why it fails: IT Operations manages day-to-day service delivery and infrastructure; it implements controls within the appetite, but does not define the organisation's tolerance for risk. It is tempting because operations owns much operational risk, yet appetite is set at board or executive level, not by a delivery function.

The GRC System Administrator.

Why it fails: A GRC System Administrator configures and maintains the governance tooling; they administer the platform that records risk appetite, but have no authority to define it. It is tempting because the role works daily with risk registers and appetite statements, yet it is a technical support function, not a governance body.

The Internal Audit Manager.

Why it fails: Internal Audit provides independent assurance and reports to the board; it evaluates whether risk appetite is respected, but setting it is a governance decision reserved for the board or executive leadership. It is tempting because audit works closely with risk frameworks, yet independence precludes defining the appetite it later assesses.

Build a custom script to write directly to the GRC database tables.

Why it fails: Writing directly to GRC database tables bypasses the tool's supported integration layer, so schema changes or upgrades break ingestion and auditability suffers. Custom database writes suit bespoke legacy systems with no API, not a CSPM tool offering standard connectors.

Manually export and import CSV files every hour.

Why it fails: Hourly CSV export and import is a batch, human-triggered process that cannot deliver the near-real-time telemetry continuous monitoring requires, and it breaks whenever the export schedule or file format changes. It is tempting because CSV import is the standard fallback for tools lacking a native API connector, and would be correct for a one-off historical data migration.

Have the CSPM tool email screenshots of security alerts to the GRC team.

Why it fails: Emailing screenshots gives unstructured images that cannot be parsed, correlated or trended, so the GRC tool holds no machine-readable data. Screenshot notification suits ad hoc awareness for staff, not automated ingestion feeding continuous monitoring dashboards.

Change the global password policy for GRC users.

Why it fails: Password policy governs authentication strength for GRC users and has no bearing on when or how control assessments are triggered. Tightening password rules is the right control when credential compromise or weak authentication is the identified risk.

Require the GRC admin to manually assign tasks to users.

Why it fails: Manual task assignment cannot trigger from control criticality, so the automatic CSA workflow never fires; a human must initiate every assessment. It is tempting because manual assignment suits ad hoc, judgement-heavy reviews where an administrator deliberately routes work. Here the stem demands criticality-driven automation, which only a rule or workflow condition evaluating that attribute can satisfy.

Disable the self-assessment feature to force all audits to be external.

Why it fails: Disabling self-assessment removes the very workflow the CSA requirement depends on, so no criticality-based trigger can fire. It is tempting when independence is the goal, since external audits avoid self-review bias; that suits mandated third-party attestation, not an automated, criticality-driven CSA process.

Change the risk rating scale from 1-5 to 1-10.

Why it fails: Changing the rating scale alters how every risk is scored; it does not restrict the heat map to cybersecurity risks. It is tempting because rescaling genuinely recalibrates risk appetite thresholds, and would be correct where the organisation needs finer granularity or alignment to a revised scoring methodology.

Delete all non-cybersecurity risks from the system.

Why it fails: Deleting non-cybersecurity risks destroys enterprise risk data instead of filtering the display, breaking the GRC register and any cross-domain reporting. It is tempting because removing irrelevant entries appears to declutter the heat map, and would be right only for genuinely obsolete records being retired through proper data-retention process.

Create a new database user for the executive.

Why it fails: A new database user grants access but applies no category filter, so the heat map still plots every risk. It is tempting because user provisioning is a genuine access-control task, and would be correct where the executive needs segregated login credentials or row-level database permissions rather than a filtered view.

The System Performance Report.

Why it fails: The System Performance Report covers availability, throughput and resource metrics, not entitlement data, so it cannot identify who holds Write access. It is tempting because it is a standard operational report, and it would be the correct choice when investigating slow response times or capacity problems in the evidence platform.

The Risk Trend Analysis Report.

Why it fails: The Risk Trend Analysis Report charts risk scores over time, containing no per-user permission data, so it cannot enumerate Write access holders. It is tempting because it is a governance report, and it would be the correct choice when demonstrating how the organisation's risk posture has shifted across reporting periods.

The Audit Finding Closure Report.

Why it fails: The Audit Finding Closure Report tracks remediation status of findings, not permission assignments, so it cannot show who holds Write access. It is tempting because it is an audit-oriented report, and it would be the correct choice when verifying that previously raised findings have been remediated and closed.

Create a separate dashboard for every assessment status.

Why it fails: Separate dashboards per status merely display each state; none is conditioned on 'Verified', so the compliance dashboard still reflects unverified assessments. Segregating views is tempting for role-based reporting, and would be correct if stakeholders needed distinct status-specific views rather than a single dashboard gated on verification.

Restrict user access to the 'Verified' status.

Why it fails: Restricting who may set 'Verified' controls data entry permissions, not the dashboard's update trigger; the dashboard still refreshes on any status change. Access restriction is tempting as a data-integrity control, and would be correct if the requirement were preventing unauthorised status changes rather than conditioning dashboard updates.

Set the report to auto-refresh every minute.

Why it fails: Auto-refresh changes only how often the dashboard polls data, not which status triggers an update; unverified assessments still appear. Frequent refresh is tempting for near-real-time visibility, and would be correct where freshness of displayed data is the requirement, not conditional update logic tied to 'Verified'.

Email all vendors every January to ask if they are ready.

Why it fails: Emails gather self-declared readiness, not evidence of due diligence, and cannot enforce the annual cadence or record assessment outcomes against Critical vendors. It is tempting because vendor communication is part of TPRM, but a questionnaire or automated assessment workflow tied to vendor risk tiering would be the correct configuration.

Hire a full-time employee to manage vendor emails.

Why it fails: A full-time employee managing vendor emails is a manual staffing measure, not a platform configuration enforcing annual due diligence. The requirement needs tier-based scheduling that automatically initiates reassessment for Critical vendors each year. Manual email handling is tempting because vendor communication is labour-intensive, but it cannot guarantee recurring, auditable review cycles.

Require vendors to login to the GRC platform daily.

Why it fails: Daily vendor logins impose an authentication frequency unrelated to due diligence scheduling. Annual reassessment of Critical vendors requires the GRC platform to trigger reviews based on vendor tier and elapsed time since the last assessment. Daily logins are tempting as a visibility measure, but they generate activity, not periodic risk evaluation.

Block access to the policy after 365 days.

Why it fails: Blocking access after 365 days enforces a hard expiry but does not initiate review, notify the owner, or capture attestation, so policies lapse rather than being reviewed. It is tempting because it guarantees action before the deadline; it would be correct for retiring obsolete documents that must not remain accessible.

Create a recurring meeting for the policy owner.

Why it fails: A recurring meeting is an external calendar reminder; it does not change policy status, trigger attestation, or produce an auditable review record inside the GRC platform. It is tempting because scheduling is cheap and familiar; it would be correct for coordinating discussion among owners where the platform lacks automated review workflows.

Require the administrator to manually reset the policy status.

Why it fails: Manual status resets depend on an administrator remembering to act each year, so the annual review is not enforced by the platform and can be missed. It is tempting because resetting status forces re-approval, which is the correct outcome; it would be right where no scheduling or workflow capability exists and reviews are genuinely ad hoc.