GRC Analyst interview preparation

Start GRC work by defining the organisation and activities being assessed. For a fictional Indian learning provider, list its enrolment portal, support process, cloud storage and external service providers. Identify where synthetic learner information enters, moves and is retained. Record excluded systems and explain why they are excluded rather than silently omitting them. Your first artifact is a scope statement linked to a simple data-flow diagram and named organisational roles, not real people's identities or invented endorsements.

Map responsibilities to decisions: a service owner understands operational impact, a control owner operates safeguards, and a risk owner has authority to accept or fund treatment of a risk. These responsibilities may overlap, but the approval boundaries must remain explicit. Use the six NIST CSF 2.0 Functions, Govern, Identify, Protect, Detect, Respond and Recover, to organise questions. The framework helps structure discussion; it does not establish that a control works merely because a corresponding policy exists.

In the fictional lab, introduce an outsourced support platform whose contract does not clearly describe evidence access or incident escalation. Record this as an unresolved dependency rather than assuming the supplier handles everything. Request a responsibility matrix, relevant contractual terms and approved escalation contacts. Decide whether the assessment can proceed with a documented limitation or needs additional evidence first. Maintain an obligation register that distinguishes legal requirements, contracts, standards and internal commitments, with an accountable reviewer for each interpretation.

Write risk as a cause, event and consequence rather than a vague label. For the fictional provider, excessive storage permissions could allow an unintended reader to retrieve synthetic enrolment documents, disrupting confidentiality and contractual commitments. Record the affected asset, evidence of the permission issue, existing safeguards and the accountable risk owner. Distinguish the current risk assessment from an inherent assessment that assumes no relevant controls. Your register should state which assessment method and assumptions are being used.

Use a clearly labelled training scale with low, medium and high likelihood and impact, each defined in words. In this example, authenticated access reduces exposure compared with public access, but broad staff membership still permits unnecessary reading. Classify current likelihood as medium and impact as high under the fictional organisation's definitions, explaining both judgments. Avoid presenting these labels as measured probabilities. Attach a synthetic access listing and data classification record so another reviewer can challenge the assessment using evidence.

Choose treatment explicitly: restrict readers to the support role, remove unused grants and introduce periodic access review. Assign a treatment owner and target review date, then estimate residual risk subject to verification. The risk owner, not the analyst alone, decides whether that residual exposure is acceptable. After a lab permission change, repeat authorised access checks and attach results. If implementation is delayed, document the reason, compensating measures and approval expiry rather than quietly marking the risk closed.

A Statement of Applicability, or SoA, connects an information security management system's necessary controls to documented decisions. Under ISO 27001, identify controls needed for risk treatment and compare them with Annex A to ensure necessary controls have not been overlooked. Record inclusion justifications and whether necessary controls are implemented, and justify exclusions from Annex A. Controls can also come from other sources. The SoA is therefore not simply a downloaded list with every item marked applicable and complete.

For the fictional enrolment service, connect access-control treatment to account provisioning, permission review and removal procedures. Create a row linking the relevant necessary control to the risk-register entry, control owner, implementation status and evidence location. Keep exact standard wording and identifiers aligned with authorised official materials rather than relying on memory. An outsourced activity may change how a control operates, but outsourcing alone does not justify exclusion if the associated risk or requirement remains within scope.

Test the SoA against a change scenario: the provider begins using a managed document platform instead of local storage. Ask which controls remain necessary, which evidence sources change and which supplier responsibilities need verification. Update the risk treatment and SoA together, retaining revision history. Your decision artifact should explain why each affected control is included, how its implementation is assessed and what evidence remains missing. A polished spreadsheet without traceability cannot establish an effective management system by itself.

Control testing asks whether a safeguard is suitably designed and whether it operated during the assessed period. A policy requiring access removal is design evidence, but it does not show that departed users actually lost access. Define the control objective, population, assessment period and expected evidence before sampling. In a synthetic joiner-mover-leaver exercise, collect approved tickets, identity records and removal timestamps. Keep sensitive fields minimised and retain evidence only within the authorised assessment repository and retention process.

Select a small training sample and explain its limits rather than claiming statistical assurance. Compare each approved departure time with the relevant account-disable record and application access status. Investigate discrepancies, including timezone differences, delayed provisioning connectors and accounts outside central identity management. Your workpaper should show the procedure, evidence reference, observation and conclusion for every sampled item. Distinguish an isolated exception from a broader control design weakness, and avoid declaring the entire population compliant based on a few records.

Introduce one synthetic case where the ticket is closed but application access remains active. Ask the control owner for an explanation and independent evidence, not merely a replacement screenshot with no collection context. Record a finding that states the criterion, condition, potential consequence and agreed action. The responsible owner should approve remediation timing and provide retest evidence. Treat contradictory records as a reason to investigate further, not an opportunity to choose whichever document makes the audit appear cleaner.

Privacy analysis begins with processing facts, not a blanket compliance label. For the fictional provider, document what learner information is collected, the stated purpose, recipients, storage locations and retention decisions. Use synthetic records rather than real learner data. Build an applicability tracker for the DPDP Act and Rules that includes the official notification reviewed, relevant provision, effective-date status and legal verification owner. Phased commencement means an enacted provision should not automatically be described as a currently operative duty.

Keep CERT-In incident obligations in a separate track. Its 2022 Directions require covered entities to report listed incidents within six hours of noticing them or being brought to notice, and maintain applicable ICT logs for a rolling 180 days within India. These are not DPDP reporting or retention rules. Record the organisation's applicability assessment, escalation contacts and evidence needed for reporting. An analyst should escalate promptly through the approved process rather than waiting for perfect certainty about every technical detail.

Run a tabletop involving suspected unauthorised access to synthetic learner documents. Build a timeline of detection, internal escalation, evidence preservation and authorised reporting decisions. Ask legal to verify which DPDP provisions and Rules apply on the exercise date using the official Gazette, and record unresolved questions explicitly. Do not invent notification deadlines or substitute a generic privacy checklist for that review. The final artifact should distinguish confirmed facts, regulatory interpretations, operational actions and the people authorised to approve each decision.