GRC Fundamentals interview questions

GRC stands for Governance, Risk and Compliance. It is an integrated way of making sure an organisation is directed properly, understands the risks to its objectives and meets its legal, regulatory and contractual obligations.

• Governance: who decides, how decisions are made, and how leadership sets direction and holds people accountable.
• Risk management: identifying, assessing, treating and monitoring things that could stop the organisation achieving its objectives.
• Compliance: demonstrating that the organisation follows the laws, regulations, standards, contracts and internal policies that apply to it.

Doing the three together avoids duplicated effort (one control can satisfy many requirements), gives leadership one view of risk, and makes security and compliance part of normal business decisions rather than a last-minute exercise.

• Threat: something that could cause harm — e.g. a ransomware group, an insider, a flood.
• Vulnerability: a weakness that a threat could exploit — e.g. an unpatched server, weak passwords, no offsite backup.
• Risk: the combination of the likelihood that a threat exploits a vulnerability and the impact if it does — e.g. 'Ransomware encrypts the unpatched billing server, stopping invoicing for several days.'

A useful way to write a risk statement is: cause (threat + vulnerability) → event → consequence (impact on objectives).

The CIA triad is the core model for information security objectives:

• Confidentiality: only authorised people can access information (encryption, access control).
• Integrity: information is accurate and has not been altered without authorisation (hashing, change control, segregation of duties).
• Availability: information and systems are accessible when needed (redundancy, backups, DR).

Many organisations also consider authenticity, non-repudiation and, for data protection, privacy.

A control is any measure that modifies risk — a policy, process, device, practice or other action.

By function:

• Preventive: stop an event happening (MFA, firewalls, segregation of duties).
• Detective: identify an event that has happened (SIEM alerts, log reviews, reconciliations).
• Corrective: limit damage and restore (backups, incident response, patching after an event).
• Others often mentioned: deterrent, compensating and directive controls.

By nature:

• Administrative / managerial (policies, training), technical / logical (encryption, access control) and physical (locks, CCTV).

Defence in depth means layering several independent controls so that if one fails, others still protect the asset.

• Example layers: security awareness → email filtering → endpoint protection → least privilege → network segmentation → monitoring → backups.

It avoids relying on a single point of failure and combines preventive, detective and corrective controls.

An information asset is anything that has value to the organisation and handles information: data sets, applications, servers, cloud services, laptops, people with key knowledge and even paper records.

• You cannot protect, risk-assess or audit what you do not know exists.
• The inventory records the owner, classification, location, business process supported and criticality of each asset.
• It feeds the risk assessment, BIA, access reviews, vulnerability scanning scope and incident response.

ISO 27001:2022 control 5.9 (Inventory of information and other associated assets) and NIST CSF 2.0 ID.AM both expect it.

Data classification labels information by how sensitive it is so that people apply the right level of protection.

• A common four-level scheme: Public, Internal, Confidential and Restricted (or Highly Confidential).
• Each level has handling rules for storage, sharing, encryption, printing, retention and disposal.
• The data owner decides the level; users apply labels; tools (DLP, sensitivity labels) enforce them.
• Keep it simple. If staff need a flowchart to choose a label, the scheme is too complex.

Least privilege means giving users, services and systems only the minimum access rights they need to do their job, and only for as long as they need them.

Need-to-know is narrower: even if someone has a clearance or a role, they only see specific information when their task requires it.

• Least privilege is about permissions (what you can do).
• Need-to-know is about information (what you can see).
• Both reduce the damage an attacker or careless insider can do with one compromised account.

Segregation of duties splits a sensitive task so that no single person can complete it end to end and hide an error or fraud.

• Classic split: request, approve, execute and reconcile should sit with different people.
• In IT: the developer who writes code should not be the one who approves and deploys it to production.
• Where staff numbers are too small for full SoD, use compensating controls: management review of logs, rotation, or automated alerts.

SoD conflicts are usually managed with a conflict matrix in the ERP or IAM tool.

• Authentication: proving who you are, such as a password plus a one-time code, a smart card or a passkey.
• Authorisation: deciding what you are allowed to do once authenticated (roles, permissions, policies).
• Accounting (or auditing): recording what you actually did, such as logins, data accessed and changes made, so actions can be traced back to a person.

Together they give you identity assurance, controlled access and accountability. Weakness in any one of them creates gaps auditors will find.

This is business email compromise (BEC), a social-engineering threat that exploits urgency and authority.

• Preventive controls: a payment policy requiring call-back verification on a known number for new or changed bank details, dual approval for payments above a threshold, and email authentication (SPF, DKIM, DMARC).
• Detective controls: banner warnings on external email, monitoring for look-alike domains, finance reconciliation.
• People controls: targeted awareness for finance and executive assistants.
• Response: if money has moved, contact the bank immediately to attempt a recall, and treat it as a security incident.

It shows why technical, administrative and people controls must work together (defence in depth).

• Policy: high-level statement of management intent and direction (what and why). Approved by senior management, changes rarely. Mandatory.
• Standard: specific mandatory requirements that support a policy — e.g. 'passwords must be at least N characters; MFA required for remote access'.
• Procedure: step-by-step instructions for performing a task (how) — e.g. the user access provisioning procedure.
• Guideline: recommended practice or advice. Not mandatory, gives flexibility.

Together they form a document hierarchy: policies set direction, standards make it measurable, procedures make it repeatable.

The Three Lines Model (updated by the Institute of Internal Auditors in 2020, previously 'Three Lines of Defence') describes roles in governance and risk management:

• Governing body: accountable to stakeholders for oversight.
• First line: operational management that owns and manages risk day to day (e.g. IT operations, business units).
• Second line: specialist functions that provide expertise, frameworks, monitoring and challenge — e.g. risk management, compliance, information security GRC.
• Third line: internal audit, providing independent and objective assurance to the governing body.

External auditors and regulators sit outside the model as additional assurance providers.

• Inherent risk: the level of risk before taking existing controls into account (or assuming no controls).
• Residual risk: the level of risk that remains after controls are applied.
• Some organisations also track target risk: the level they aim to reach after planned treatments.

Example: storing patient data on internet-facing systems has a high inherent risk. With MFA, encryption, monitoring and patching in place, the residual risk may be medium. If that is still above appetite, more treatment is planned.

• Framework: a structured set of good practices you can adopt and adapt, such as NIST CSF, COBIT or the NIST AI RMF. Usually voluntary.
• Standard: a formal, published specification you can be audited or certified against, such as ISO/IEC 27001 or PCI DSS.
• Regulation or law: mandatory rules made by a government or regulator, such as GDPR, HIPAA, Singapore's PDPA or India's DPDP Act. Breaking them brings penalties.
• Contract requirement: obligations you agreed to with a customer or partner, such as 'maintain SOC 2 Type II' or 'notify us of breaches within 24 hours'.

A good obligations register lists all four, because contracts are often stricter than the law.

An obligations register is a single list of every legal, regulatory, contractual and voluntary requirement that applies to the organisation, with an owner and the controls that meet it.

1. Identify sources: laws in each country of operation, sector regulators, standards you certify to, key customer contracts and internal policies.
2. Break each source into specific, testable obligations.
3. Assign an owner and map each obligation to controls in your control library.
4. Record evidence, testing frequency and status.
5. Set up horizon scanning so new or changed obligations are added (regulatory change management).

Security and privacy by design mean building protections into systems, products and processes from the start, rather than bolting them on after go-live.

• GRC embeds checkpoints into the project lifecycle: a security and privacy screening at idea stage, a risk assessment or DPIA at design, security testing before release.
• Requirements come from the obligations register and the data classification.
• Defaults should be the most protective setting (privacy by default, GDPR Article 25).

ISO 27001:2022 controls 5.8 (information security in project management) and 8.25–8.29 (secure development) support this.

• Control objective: what you want to achieve. Example: 'Only authorised users have access to production systems.'
• Control activity: the specific action that achieves it. Example: 'The application owner reviews all production access quarterly and removes access that is no longer needed.'
• Control test: how you check it works. Example: 'Select 2 of 4 quarterly reviews, confirm they were completed on time, and reperform removal for 10 flagged users.'

Writing controls at this level of precision is what makes them auditable.

1. Assess the immediate risk: what data, how much, who has access, are links shared publicly?
2. Contain sensibly: restrict public links and stop new uploads of sensitive data, without shutting down the team's work overnight.
3. Understand why they used it. Usually the approved tool is missing a feature or is too slow.
4. Decide: bring the app under governance (vendor assessment, SSO, contract) or migrate the data to an approved tool.
5. Fix the root cause: a quick request process for new tools, plus CASB or SaaS discovery to spot it earlier.

Treat it as a learning moment, not a punishment, unless policy was knowingly broken.

• Decline politely and clearly. Misstating control status is a matter of integrity and can expose you and the organisation to serious consequences.
• Explain the risk: auditors usually find it anyway, and a concealed failure turns a minor finding into a credibility problem.
• Offer a constructive path: record the control as 'not effective' or 'partially effective', document the remediation plan with dates, and show any compensating control.
• If pressure continues, escalate through the proper channel (CISO, compliance head, ethics line).

ISACA's Code of Professional Ethics and most certification bodies expect exactly this behaviour.

• Classify by the most sensitive element. Patient names linked to appointment information are health-related personal data, so the whole set takes the highest relevant level (for example, Restricted).
• Check whether the sensitive fields are really needed. If analysts only need the survey scores, provide a de-identified extract instead.
• Confirm with the data owner, who makes the final decision.
• Apply the handling rules: approved storage, access only for named roles, encryption, retention limits.
• Note that 'anonymous' survey data can become identifiable once it is combined with names and dates.

Zero trust is a security model that assumes no user, device or network is trusted by default. Every access request is verified explicitly, using identity, device health and context, and access is limited and continuously re-evaluated.

• Core ideas (NIST SP 800-207): verify explicitly, use least-privilege access, assume breach.
• It shifts controls from the network perimeter (VPN, firewall zones) to identity, device and data.
• GRC impact: control descriptions, risk assessments and audit tests change. For example, 'is the device compliant before access?' replaces 'is the user on the corporate network?'.
• It is a journey, not a product. Maturity models such as CISA's Zero Trust Maturity Model help plan and measure progress.

• ERM covers all risks to business objectives: strategic, financial, operational, legal, reputational. It is usually owned by a CRO or risk committee and uses frameworks such as COSO ERM or ISO 31000.
• Cyber risk management covers risks from information and technology, using frameworks such as ISO 27005, NIST SP 800-30 or FAIR.
• They should connect through a common risk taxonomy, shared impact scales and escalation rules, so top cyber risks appear in the enterprise register in business language.
• Avoid two disconnected registers with different scoring. The board then cannot compare a cyber risk with a market or credit risk.

• Do not argue in compliance jargon. Translate GRC into what the CEO cares about: revenue, licence to operate, customer trust and avoiding surprises.
• Show the value: deals won because of ISO 27001 or SOC 2, regulatory exposure avoided, audit findings closed, and the cost of questionnaires handled faster.
• Show the efficiencies already made, and offer more: automating evidence, rationalising duplicate frameworks into one control set, retiring low-value activities.
• Present options with consequences: 'With 50% we can keep ISO 27001 and HIPAA but must drop SOC 2, which three enterprise customers require.'
• Let leadership make an informed decision, and record it as a risk acceptance if they reduce coverage.