GRC Analyst interview questions

I map each requirement to the objective and activity it actually covers, not merely to similar wording.

• Each row identifies the source citation and version, common-control ID, covered assertion, and any uncovered condition.
• For quarterly privileged-access reviews, I record the population, reviewer, decision criteria, cadence, and retained approvals as implementation facts.
• I label each relationship full, partial, or supporting and require framework-owner approval before claiming full coverage.

I build the library around operating activities, with one stable record for each distinct control.

• Each record contains an objective, owner, frequency, scoped systems, procedure, evidence specification, test method, and version history.
• Framework requirements link many-to-many to that record, while framework-specific conditions remain explicit extensions.
• I split a control when activities have different owners, frequencies, populations, or failure modes because one test cannot support them all.

An obligation states what must be achieved, a control is how the organization addresses it, and evidence shows that the control operated.

• A PCI requirement or contract clause enters an obligations register with source, applicability, owner, and effective date.
• One or more controls implement it through named activities, such as disabling terminated accounts within 24 hours.
• An Okta log and approved termination ticket support operation for a period, but neither artifact is the control itself or proof of every related obligation.

I turn the objective into a falsifiable statement that names the population, expected condition, period, and criteria.

• For production access, the assertion may be that every privileged account in the complete quarter-end population was authorized by the system owner and unnecessary access was removed on time.
• The procedure obtains a complete system-generated population, validates its completeness, and inspects selected approvals, removals, and timing against the defined criteria.
• The evidence specification identifies export parameters and timestamp, approval records, removal tickets, and exceptions so another tester can reproduce the conclusion.

One artifact can be reused only when its provenance, scope, period, and attributes satisfy each linked control specification.

• A monthly IAM export may support inventory and review controls if it is system-generated, complete, dated, and tied to an approved review.
• The evidence catalog stores the source system, report parameters, extraction time, covered population, custodian, and immutable location.
• I keep separate conclusions per control because the export may prove population completeness but not timely approval or removal.

I document which responsibility is inherited, which remains with the consuming team, and what validates the boundary.

• The record names the provider, service scope, control statement, assurance source, validity period, and consuming systems.
• For AWS physical security I may rely on a relevant SOC report, while our team still owns region selection, IAM, logging, and customer responsibilities.
• A service change, report qualification, uncovered region, or expired assurance triggers reassessment instead of silent continued reliance.

I establish scope from business services and regulated data flows before selecting systems or controls.

• The scope pack includes legal entities, products, locations, data-flow diagrams, system and asset inventories, interfaces, vendors, and explicit exclusions.
• Every exclusion has a factual rationale, such as no connectivity or relevant data handling, plus an accountable approver.
• I reconcile diagrams to CMDB, cloud accounts, repositories, identity tenants, and vendor records so an outdated inventory does not create a false boundary.

I reuse a test only when the control, scope, period, population, attributes, and assurance standard support the second purpose.

• The reuse memo links the original workpaper, tester competence and independence, sample, exceptions, test date, and exact requirements covered.
• A SOC 2 access review test may support ISO for the same systems and period, but not a PCI population containing additional CDE systems.
• If timing or criteria differ, I perform a roll-forward or incremental test and record the remaining gap rather than copying the conclusion.

I mark the common awareness control as partial and model role-based training as an additional requirement or activity.

• The mapping records which clauses the annual course satisfies and leaves the role-specific audience, content, and completion evidence visibly open.
• I add targeted training for administrators or payment staff with an owner, trigger, due date, roster, and completion record.
• Coverage changes to full only after design review and operating evidence show both activities work for the scoped population.

I version the source requirement, mapping decision, and control together so historical assurance conclusions remain reproducible.

• The change record captures old and new citations, effective date, impact assessment, mapping owner, approver, and affected tests and evidence requests.
• A diff review classifies the change as editorial, clarified, expanded, new, or retired and opens gaps for any new obligation.
• Approved mappings are baselined per audit period, while later changes use change control rather than silently rewriting prior workpapers.

I run it as a staged assurance project: define scope and criteria, remediate readiness gaps, operate controls for the period, support testing, and close the report.

• Readiness produces the system boundary, service commitments, selected Trust Services Criteria, control matrix, owners, evidence plan, and gap register.
• Before the period starts, key controls are implemented and owners can produce complete populations and repeatable evidence on schedule.
• During fieldwork I manage walkthroughs, PBC requests, samples, deviations, management responses, representation materials, and final report review with the CPA firm.

I treat a Type II report as assurance bounded by its scope and period, not as a general badge for the vendor.

• I first compare the system description, covered services and locations, selected Trust Services Criteria, and report period with our use of the service.
• I then read control test procedures and results, deviations, and management responses, assessing their pervasiveness and relevance to the controls we depend on.
• Finally, I map CUECs to our responsibilities and review the subservice-organization method, complementary controls, and any coverage gaps.

The scoped controls must be designed, assigned, implemented, and capable of producing evidence from the first day of the period.

• I baseline the system description, selected criteria, control matrix, subservice treatment, CUECs, owners, frequencies, and evidence sources.
• For recurring controls I dry-run population generation, timestamps, approvals, and retention instead of waiting for fieldwork to reveal gaps.
• Open readiness items are remediated before day one, excluded through a defensible scope change, or accepted with the likely report impact.

A walkthrough confirms how a control is designed and implemented by tracing a real instance with the people who perform it.

• I capture the owner, trigger, systems, steps, frequency, population source, retained evidence, exceptions, and handoffs.
• The owner demonstrates one recent item from initiation through approval and completion, and I reconcile it to the written control.
• The workpaper records attendees, date, artifact references, design gaps, and follow-ups without treating the walkthrough as full operating-effectiveness testing.

I validate how the population was generated before relying on any sample selected from it.

• The PBC package includes system of record, report name or query, parameters, covered dates, filters, row count, extraction timestamp, and preparer.
• I reconcile counts to an independent source, inspect first and last dates, test excluded statuses, and preserve the generated file and parameters.
• If a Jira export omits emergency changes or an API paginates incompletely, I regenerate it before the auditor selects samples.

I make populations and item-level evidence audit-ready while leaving sample selection and sufficiency judgments to the service auditor.

• The control matrix states frequency and expected attributes such as requester, approver, timestamp, test result, and closure evidence for each change.
• I provide a complete population in a reproducible format and maintain an index so any selected item can be retrieved without alteration.
• I track selections, replacements, missing evidence, deviations, and due dates but never substitute convenient items without the auditor’s documented reason.

CUECs are controls the service organization assumes user entities operate for its controls to achieve the stated criteria.

• A payroll provider may require the customer to authorize users, review payroll inputs, and remove access for terminated staff.
• The customer maps each applicable CUEC to an internal owner, procedure, evidence, and test or records why it is not applicable.
• A clean provider opinion does not cover the customer’s failure to operate a required CUEC, so the CUEC section belongs in the review workpaper.

A subservice organization performs functions relevant to service commitments, so its role and control dependencies must be explicit.

• I identify the service, data and processes involved, relevant controls, assurance reports, period coverage, exceptions, and management monitoring.
• Complementary subservice organization controls describe what the provider must operate, while our controls cover selection, configuration, monitoring, and incidents.
• Cloud hosts and payment processors are assessed for relevance rather than automatically listed merely because they are vendors.

The carve-out method excludes the subservice organization’s controls from examination, while the inclusive method includes them in the described system and testing.

• Under carve-out, the description identifies omitted functions and complementary subservice organization controls, and management monitors the provider separately.
• Under inclusive, relevant provider controls, management assertion, and auditor testing are included, requiring cooperation and suitable evidence from that organization.
• Neither method removes our responsibility to understand dependencies, CUECs, report periods, exceptions, and customer commitments.

I establish the condition and extent, remediate transparently, and leave the assurance conclusion to the service auditor.

• The issue record captures the expected control, observed item and dates, cause, population size, duration, and any compensating activity, followed by a search for similar cases.
• The response states the facts, risk, immediate correction, corrective action, owner, due date, and effectiveness evidence without arguing the exception away.
• The auditor independently considers frequency, pervasiveness, other evidence, and report impact, and remediation cannot erase the original test result.