GRC / Compliance Analyst interview questions

No. Cloud runs on a shared responsibility model: the provider secures the underlying infrastructure ('security of the cloud'), but you remain responsible for your data, identity and access management, configuration, and — for IaaS — the OS and patching ('security in the cloud'). The large majority of cloud breaches are customer-side misconfigurations like public buckets and over-permissive IAM, not provider failures. Assuming the provider secures your data is how those breaches happen.

Sending customer PII to an external API exposes it to a third party's processing and retention and can breach privacy obligations. Minimize and redact what's sent, confirm the provider's data-use/retention terms and a data-processing agreement (or no-training guarantees), or move to a private deployment for sensitive data. Key length is irrelevant, and sending more PII increases the exposure.

Auditors test for evidence, not intent: show the access-review policy, dated records of each review with approver sign-off, and confirmation that flagged access was revoked and verified. A verbal confirmation proves nothing repeatable, a promise to start next quarter shows the control was not operating in the audit period, and an org chart describes reporting lines, not access decisions. Only the dated, attributable artifacts demonstrate the control operated as designed across the whole period.

Backups are necessary but not sufficient: disaster recovery and business continuity are the tested capability to restore operations within agreed recovery time and recovery point objectives (RTO/RPO), which requires a documented plan, mapped dependencies, runbooks, and validated restores — not just the existence of backup files. Agreeing they're the same conflates a data copy with an operational capability. DR isn't merely buying insurance, which transfers financial loss but doesn't restore systems. And backups don't make a DR plan unnecessary — untested backups routinely fail when they're finally needed. The clarification: DR must be exercised, not assumed.

Frameworks set a minimum bar and can be fully met while real risk remains, so a passed checklist doesn't mean secure: raise the gap, assess its risk, and drive treatment regardless of the compliance status. Concluding it's secure because compliance passed is a dangerous conflation of two different things. Removing the gap from the report is misrepresentation and potentially fraud. Waiting for the next audit cycle knowingly leaves a real exposure open. The mature stance treats compliance as evidence of a floor, not a ceiling, and acts on risk you can actually see.

Inconsistent handling usually means there's no shared definition of sensitivity, so the foundational control is a data classification scheme (e.g., public/internal/confidential/restricted) with defined handling, storage, and sharing requirements per level, letting teams apply proportionate controls. Encrypting nothing 'to keep things simple' or treating all data as public strips protection from data that needs it. Deleting all data older than a day destroys records the business and the law require. Only a classification scheme aligns the strength of controls to the actual sensitivity of the data.

Leaver risk is lingering access, so the control to verify is timely deprovisioning of every access path — directory accounts, SSO, VPN, privileged and service credentials, and third-party SaaS — reconciled against the joiner/mover/leaver (JML) process. Assuming HR handles it all without verification leaves gaps no one owns. Keeping the account active 'in case they come back' is standing, unmonitored risk. Disabling only email ignores the many other systems the person could still reach. The point is to verify access is actually and fully removed, not to trust that it was.

PCI DSS scope covers systems that store, process, or transmit cardholder data plus anything connected to or able to affect them, so effective network segmentation isolates the cardholder data environment (CDE) and removes unrelated systems from scope, shrinking cost, effort, and risk. Encrypting every server doesn't define a boundary and connected systems stay in scope; adding untargeted firewalls everywhere isn't segmentation if it doesn't restrict and validate the data flows; and stopping people reading card numbers aloud is hygiene, not a scoping control. The systemic answer is to control where cardholder data lives and what can reach it.

Governance means the risk is captured and managed, not informally handled: record it in the risk register with assessed likelihood and impact, assign an accountable owner, decide and document the treatment (mitigate, transfer, accept, or avoid), and set a review date. Fixing it yourself on the spot skips ownership, prioritisation, and tracking, and may not even be your call. Ignoring it until it becomes an incident is negligent, and emailing everyone creates noise but no accountability or follow-through. The register turns a one-off observation into a tracked, owned, revisited decision.

A SOC 2 report only assures you if you actually read it: confirm it's the right type (Type II tests operating effectiveness over time, Type I only design at a point), check the scope and which Trust Services Criteria it covers, that the period is current and has no gap, what opinion the auditor gave (unqualified vs qualified), and review the noted exceptions plus the complementary user-entity controls (CUECs) you're responsible for. Merely confirming the report exists — or judging it by its cover logo or page count — tells you nothing about the vendor's actual control effectiveness or your residual obligations.

Sending PII to a third party extends your trust boundary, so first run a vendor security assessment — data handling, encryption, access controls, certifications like SOC 2 / ISO 27001, sub-processors, breach-notification terms — and put a data-processing agreement (DPA) in place before any PII flows. A pricing contract or a sales rep's verbal word is not due diligence. And a 'polished website' tells you nothing about how the vendor actually protects data; you remain accountable for it.

Breach handling is governed by law and contract: work with legal to meet mandatory notification timelines (such as GDPR's 72 hours to the supervisory authority) and inform affected parties accurately. Concealment risks far larger fines, regulatory action, and reputational damage when it surfaces later. Dumping raw, unverified technical details prematurely can mislead customers and aid attackers. Scapegoating an individual employee is neither accurate, lawful, nor effective crisis management — it deflects from the organization's accountability.

When you can't remediate, you manage the risk: reduce exposure with compensating controls (network segmentation, tightened access, enhanced monitoring), quantify the residual risk, and have the accountable business owner formally accept it with a defined review date. Unilateral shutdown oversteps the CISO's authority and harms the business. Ignoring it because it can't be fixed is negligence. Omitting it from the risk register hides accountability, breaks audit trails, and means no one is on record owning the decision.

DAC lets the data owner grant access at their discretion; MAC enforces access centrally via labels/clearances and is non-discretionary; RBAC grants access through job roles; ABAC evaluates attributes (user, resource, environment) against policy for fine-grained, context-aware decisions.

Business continuity (BCP) is the broad strategy to keep critical business functions operating during and after a disruption; disaster recovery (DRP) is the IT-focused subset that restores systems and data. RTO is the maximum tolerable time to restore a function; RPO is the maximum tolerable data loss measured in time.

Classification labels data by sensitivity so the organization applies controls proportional to value and risk, avoiding both under-protection and wasteful over-protection. The data owner (a business role) sets the classification and accepts risk, while the data custodian (often IT) implements and maintains the protective controls.

Due diligence is the ongoing investigation and understanding of risks (knowing what should be done), while due care is taking the reasonable actions a prudent person would take to address them (actually doing it). Diligence is research and oversight; care is implementation and maintenance.

Identity lifecycle management governs an account from creation to retirement: provisioning at onboarding (joiner), adjusting entitlements on role change (mover), and timely deprovisioning at exit (leaver), with periodic access reviews throughout. The most common failures are privilege creep on movers and orphaned accounts from missed deprovisioning.

A policy is the high-level mandatory statement of management intent; a standard is a mandatory specific rule that enforces policy (e.g. AES-256); a procedure is the mandatory step-by-step how-to; a guideline is an optional recommendation. Policies, standards, and procedures are mandatory, while guidelines are discretionary.

Quantitative analysis assigns hard monetary values so you can compute expected loss; qualitative analysis ranks risk on relative scales (high/medium/low) using expert judgment. Quantitative uses SLE = asset value x exposure factor, ARO = expected occurrences per year, and ALE = SLE x ARO to express annual expected loss in dollars.

You can mitigate (reduce likelihood/impact with controls), transfer (shift the financial impact via insurance or contracts), avoid (stop the risky activity entirely), or accept (knowingly tolerate the residual risk). The choice depends on risk appetite and a cost-benefit comparison against the risk's expected loss.

Encryption in transit (TLS) protects data moving over the network from eavesdropping and tampering; enforce TLS everywhere and reject plaintext. Encryption at rest protects stored data on disks and backups, typically via KMS-managed keys using envelope encryption. Both are baseline controls, but neither stops an authorized-but-malicious request — the service decrypts transparently for valid callers — so access control still matters most.

A user is a long-lived identity with permanent credentials; a role is an identity with no permanent credentials that any trusted principal can assume to get short-lived tokens; a policy is the JSON document that grants permissions, attached to either. Least privilege means preferring roles over users, scoping policies to specific actions and resources, and granting only what a task needs — then reviewing and pruning over time.

The provider secures the cloud itself — physical data centers, hardware, the hypervisor, and the managed services they run. You secure what you put in the cloud — your data, identities, configurations, OS patching where applicable, and access controls. The exact line shifts: with IaaS you own the OS up, with SaaS you mostly own data and access.

A digital signature is the hash of a message transformed with the signer's private key. The verifier recomputes the hash, applies the signer's public key, and checks they match. Because only the signer holds the private key, a valid signature proves the message came from them (authenticity), wasn't altered (integrity), and that they can't credibly deny it (non-repudiation).

The CIA triad is the three core goals of information security: confidentiality (only authorized parties can read data), integrity (data isn't altered without authorization), and availability (authorized users can access systems when needed). Almost every control maps to one or more of these.

A vulnerability is a weakness (unpatched software). A threat is an actor or event that could exploit it (a ransomware group). Risk is the combination of likelihood that a threat exploits a vulnerability and the impact if it does. Risk = threat x vulnerability x impact, and it's what you actually prioritize.

Controls are classified two ways. By type: administrative (policies, training, procedures), technical/logical (firewalls, MFA, encryption), and physical (locks, badges, cameras). By function: preventive (stop an event — MFA, access control), detective (find an event — SIEM, IDS, audit logs), corrective (fix after — restore from backup, patch), deterrent (discourage — warning banners), and compensating (an alternative when the primary control isn't feasible). Defence in depth layers these so no single control failure leads to compromise.

GDPR Article 5 sets seven principles: lawfulness/fairness/transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality, and accountability. For a personal data breach, the controller must notify the competent supervisory authority without undue delay and where feasible within 72 hours of becoming aware (Article 33). If the breach is likely to result in a high risk to individuals, the controller must also notify the affected data subjects without undue delay (Article 34).

Governance is how leadership sets direction, defines accountability, and aligns security with business objectives — the policies, roles, and oversight that say what 'good' looks like. Risk management is the process of identifying, assessing, treating, and monitoring threats to those objectives. Compliance is demonstrating adherence to obligations — laws, regulations, contracts, and internal policy. Governance drives risk decisions; risk informs which controls you need; compliance evidences that those controls meet required standards. Compliance is an outcome of good GRC, not a substitute for security.

HIPAA (the US Health Insurance Portability and Accountability Act) protects Protected Health Information (PHI). The Privacy Rule governs use and disclosure of PHI; the Security Rule applies to electronic PHI (ePHI) and requires three categories of safeguards — administrative, physical, and technical. It applies to covered entities (providers, health plans, clearinghouses) and to business associates that handle PHI on their behalf, bound by Business Associate Agreements. The Breach Notification Rule sets obligations to notify individuals, HHS, and sometimes the media.

ISO/IEC 27001 specifies the requirements for an Information Security Management System (ISMS): a risk-based, top-down framework of policies, processes, roles, and continual improvement (Plan-Do-Check-Act) governing how an organisation manages information security. Annex A is a reference catalogue of controls. You don't apply them all blindly — you run a risk assessment, decide which controls are needed, and document the include/exclude decisions with justification in a Statement of Applicability (SoA).

The NIST Cybersecurity Framework organises cybersecurity outcomes into core functions. In CSF 2.0 there are six: Govern (the new overarching function for strategy, roles, risk decisions, and oversight), Identify (understand assets and risks), Protect (safeguards to limit impact), Detect (find events), Respond (act on incidents), and Recover (restore capabilities). They are not strictly sequential — they run continuously and together describe a full lifecycle of managing cyber risk.

PCI DSS (Payment Card Industry Data Security Standard) is a security standard maintained by the PCI Security Standards Council that applies to any organisation that stores, processes, or transmits cardholder data. It is organised around control objectives covering a secure network, protection of stored cardholder data, vulnerability management, strong access control, monitoring/testing, and an information security policy. Scope is everything in the cardholder data environment (CDE) — so segmentation, tokenisation, and not storing data you don't need are the main ways to shrink scope.

Treat awareness as behaviour change, not an annual checkbox. Make it role-based (a developer needs different content than finance), continuous rather than a once-a-year slideshow, and grounded in real risks like phishing, social engineering, and data handling. Reinforce it with phishing simulations, just-in-time nudges, and clear reporting channels. Measure outcomes — phishing report rates, click rates, time-to-report — not just completion percentages. Build a culture where people report mistakes without fear, because fear suppresses reporting.

A KPI (Key Performance Indicator) measures how well a security activity is performing against its objective — for example mean time to detect, patch SLA compliance, or percentage of systems with MFA. A KRI (Key Risk Indicator) is a forward-looking signal that risk exposure is increasing toward an unacceptable level, with a threshold that should trigger action — for example the number of overdue critical patches, count of unmanaged devices, or failed access reviews trending up. KPIs tell you how you're doing; KRIs warn you about where you're heading.

A SOC 2 Type I report assesses whether a service organisation's controls are suitably designed at a single point in time. A Type II report goes further: it tests whether those controls operated effectively over a review period, typically 3 to 12 months. Both are based on the AICPA Trust Services Criteria — Security (the required common criteria), plus optional Availability, Processing Integrity, Confidentiality, and Privacy.

Treat vendor risk as a lifecycle, not a one-off questionnaire. Inventory your third parties and tier them by criticality and data sensitivity. Run due diligence proportional to tier — review SOC 2 / ISO 27001 reports, security questionnaires, pen-test summaries, and the data and access involved. Bake controls into the contract (security requirements, right to audit, breach notification, data handling, subprocessors). Then monitor continuously, not just at onboarding, and have a clean offboarding process to revoke access and recover or destroy data. Fourth-party (subprocessor) risk matters too.

A risk assessment identifies assets and their value, the threats and vulnerabilities that could affect them, then estimates risk as a function of likelihood and impact. You can do it qualitatively (high/medium/low, fast and subjective) or quantitatively (SLE × ARO = ALE, data-driven but harder). Frameworks like NIST RMF and ISO 27005 give it structure, and the output feeds risk treatment: mitigate, transfer, avoid, or accept.

Vulnerability management is a continuous loop: discover assets and vulnerabilities (scanning, asset inventory), prioritize by real risk (CVSS plus exploitability, exposure, and asset criticality — frameworks like EPSS and SSVC help), remediate or mitigate, verify the fix, and report on trends and SLAs. The scan is the easy part; the discipline is prioritizing and closing the loop so risk actually goes down over time.

A vulnerability scan is an automated, breadth-first inventory of potential weaknesses, often with false positives. A penetration test is human-driven: it validates findings, chains them together, and demonstrates real business impact through actual exploitation.

A good report serves two audiences: an executive summary that frames business risk for leadership, and detailed, reproducible findings with evidence, accurate risk ratings, and prioritized remediation for the technical team. The report — not the exploit — is the deliverable.

Least privilege means every user, process, or service gets only the minimum access required to do its job, and nothing more. It shrinks the blast radius of any compromise or mistake. You enforce it with role-based access, just-in-time elevation, regular access reviews, and removing standing admin rights.