GRC Program practice questions

The number of tickets opened in the GRC helpdesk.

Why wrong: This measures support load, not GRC effectiveness.

The total storage space consumed by evidence files.

Why wrong: Infrastructure metrics are not business value metrics.

The number of users logged into the GRC platform daily.

Why wrong: System usage is a vanity metric.

Disabling the record deletion permission for all users.

Why wrong: Deletion is different from modification; record locking is the more comprehensive control.

Setting the record visibility to 'Public'.

Why wrong: Visibility controls who sees the record, not whether it can be changed.

Setting the 'Draft' workflow state to permanent.

Why wrong: Draft states are for work-in-progress, not final evidence.

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

Why wrong: This bypasses the CISO approval requirement.

Change the default notification email template for findings.

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

Modify the User Permission set for the CISO account.

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

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

Why wrong: This creates a 'shadow IT' risk and does not solve the underlying platform data linkage issue.

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

Why wrong: While helpful, taxonomy alignment is secondary to the functional mapping logic of the CCF.

Disable the Regulatory Requirement module to focus only on Risks.

Why wrong: This abandons the goal of integration.

Setting all user passwords to match the local language.

Why wrong: Language settings do not address data residency legal requirements.

Encrypting the entire GRC database with one key.

Why wrong: Encryption protects data, but does not dictate where data resides.

Conducting a system-wide vulnerability scan.

Why wrong: Scanning checks for security flaws, not regulatory residency compliance.

Update the manual risk assessment survey annually.

Why wrong: Annual manual updates fail the 'real-time' requirement for risk management.

Increase the frequency of full organizational risk assessments.

Why wrong: Increasing frequency does not address the underlying data calculation issue.

Require the CISO to manually approve all risk score changes.

Why wrong: This introduces a bottleneck and doesn't fix the underlying data linkage.

Assign Global Administrator rights to the lead auditor.

Why wrong: This violates the principle of least privilege.

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

Why wrong: SSO provides authentication but does not define granular authorization levels within the GRC module.

Configure a shared service account for all audit activities.

Why wrong: Shared accounts destroy audit trails and non-repudiation.

The system audit log.

Why wrong: Logs record user behavior, not the posture of risk management.

The User Provisioning interface.

Why wrong: Provisioning manages user access, not risk data.

The API integration module.

Why wrong: APIs are for data ingestion, not presentation for decision makers.

To allow every department to have its own data repository.

Why wrong: This creates silos, which GRC aims to eliminate.

To minimize the cost of software licenses.

Why wrong: Licensing is a secondary consideration to data integrity.

To make the GRC platform run faster.

Why wrong: Performance is determined by database architecture, not data policy.

Requiring the Risk Owner to sign a hard copy document.

Why wrong: Hard copies are inefficient and disconnected from the GRC platform.

Disallowing all risk exceptions in the system configuration.

Why wrong: This is unrealistic for operational agility and often leads to workarounds.

Setting a manual reminder on the CISO's calendar.

Why wrong: Manual processes are prone to failure and are not scalable.

The IT Operations Manager.

Why wrong: They manage operational assets, not overarching risk strategy.

The GRC System Administrator.

Why wrong: They manage the platform, not the business strategy.

The Internal Audit Manager.

Why wrong: They assess compliance against appetite, they do not set it.

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

Why wrong: Direct DB manipulation is dangerous and unsupported by most GRC vendors.

Manually export and import CSV files every hour.

Why wrong: Manual processes are inefficient and prone to human error.

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

Why wrong: This is not a structured data integration and cannot be easily tracked.

Change the global password policy for GRC users.

Why wrong: This is a security setting, not a workflow trigger.

Require the GRC admin to manually assign tasks to users.

Why wrong: Manual assignment is inefficient for large-scale control programs.

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

Why wrong: This increases cost and reduces the scope of control oversight.

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

Why wrong: Changing scales affects the data, not the visibility of a category.

Delete all non-cybersecurity risks from the system.

Why wrong: Data loss is unacceptable and not a configuration solution.

Create a new database user for the executive.

Why wrong: User permissions do not change the visualization scope.

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

Why wrong: This causes confusion and loses the original context of the internal control.

Create separate GRC instances for every framework adopted.

Why wrong: This creates silos and prevents cross-framework reporting.

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

Why wrong: Custom code is difficult to maintain during platform upgrades.

The System Performance Report.

Why wrong: This report measures latency and CPU usage.

The Risk Trend Analysis Report.

Why wrong: This shows the movement of risk scores over time.

The Audit Finding Closure Report.

Why wrong: This shows task completion statistics, not system access.

Create a separate dashboard for every assessment status.

Why wrong: This is inefficient and hard to manage.

Restrict user access to the 'Verified' status.

Why wrong: This restricts the process, not the report visibility.

Set the report to auto-refresh every minute.

Why wrong: Refresh frequency does not control the data state.

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

Why wrong: Manual outreach is not a scalable or reliable GRC control.

Hire a full-time employee to manage vendor emails.

Why wrong: This is an administrative overhead approach, not a GRC platform solution.

Require vendors to login to the GRC platform daily.

Why wrong: This is burdensome for vendors and not a compliance best practice.

Block access to the policy after 365 days.

Why wrong: This prevents legitimate access to the policy document.

Create a recurring meeting for the policy owner.

Why wrong: This is outside the platform and cannot be audited.

Require the administrator to manually reset the policy status.

Why wrong: Manual administrative intervention is not scalable.

The 'Report' generator.

Why wrong: This reports on data, it does not define the business structure.

The 'Policy' library.

Why wrong: This stores documentation, not organizational data.

The 'Incident' tracking module.

Why wrong: This tracks events, not organizational structure.