GRC Interview Questions

• Governance - the policies, procedures, and organizational structure that set security direction (who decides what, and how).
• Risk management - the ongoing cycle of identifying, assessing, treating, and monitoring risks.
• Compliance - adherence to laws, regulations, and standards (which are themselves usually a codified subset of "good risk management").

They're bundled because they reinforce each other: governance sets the policies that risk management operationalizes, and compliance is largely evidence that governance and risk management are actually working. Treating them as three disconnected functions (a common anti-pattern) leads to duplicated controls, audit fatigue, and gaps where nobody owns a given risk. See GRC Overview.

• Accept - acknowledge the risk and monitor it (e.g. a low-severity finding on a legacy system slated for decommission in a month).
• Mitigate - implement controls to reduce likelihood/impact (e.g. adding MFA to reduce credential-stuffing risk).
• Transfer - shift the risk elsewhere, typically via insurance or outsourcing (e.g. cyber insurance, or using a PCI-compliant payment processor instead of handling card data yourself).
• Avoid - eliminate the risky activity entirely (e.g. deciding not to build a feature that would require storing sensitive biometric data at all).

A good interview answer picks a treatment based on cost of mitigation vs. cost of the risk materializing - not defaulting to "mitigate everything."

Think of them as a hierarchy of decreasing authority and increasing specificity: policies state high-level intent ("all data must be encrypted at rest"), standards define specific required parameters ("use AES-256"), procedures are step-by-step instructions to meet the standard ("here's how to configure disk encryption on our EC2 fleet"), and guidelines are recommended-but-not-mandatory practices. Auditors typically check whether procedures actually implement the standards, and whether standards actually satisfy the policy - gaps anywhere in that chain are common audit findings.

ISO 27001 certifies that an organization runs a systematic Information Security Management System (ISMS) - not that any specific technology is secure. It requires identifying information assets, assessing risks to them, implementing controls from Annex A (93 controls across 4 themes: organizational, people, physical, technological), and continually monitoring/improving. For engineers, the practical impact is usually: expect to document what you're protecting and why, expect periodic control effectiveness reviews, and expect that "we did it once" isn't enough - ISO 27001 audits check for continual improvement, not a one-time snapshot. See ISO/IEC 27001:2022.

NIST CSF is a five-function framework (Identify, Protect, Detect, Respond, Recover) used mainly for organization-wide risk communication and prioritization - it's lightweight and works well as an executive-facing maturity model. NIST RMF is a seven-step, more prescriptive process (Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor) aimed at system-level authorization, most associated with US federal/government system accreditation (ATO).

In practice: use CSF to structure a security program and talk to leadership about posture; use RMF when you need to formally authorize a specific system for operation with documented, assessed controls. See NIST CSF and NIST RMF.

Security protects data from unauthorized access/threats (encryption, access control) - the question is "can we protect it?" Privacy governs whether and how data should be used at all (consent, purpose limitation, individual rights) - the question is "should we?" You can have excellent security around data you had no right to collect in the first place, which is exactly the scenario regulators (and interviewers) are probing for. See Data Privacy.

You must delete their personal data without undue delay, including from backups where feasible - not just deactivate the account. It gets complicated with: data replicated across multiple systems/vendors (do you have a process to propagate deletion?), data baked into ML training sets (deleting a source record doesn't un-train a model that learned from it - see "model unlearning" in AI Data Security), legal holds or other lawful bases that override the erasure right (e.g. financial record retention requirements), and backups that can't be selectively purged without a restore-and-rebuild process. A strong answer acknowledges the "easy in policy, hard in distributed systems" gap.