GRC Analyst interview questions

Governance sets direction and accountability, risk management handles uncertainty, and compliance tracks obligations and proof.

• Governance appears in artifacts such as committee charters, approved policies, decision rights, and reporting cadence.
• Risk work identifies scenarios, rates likelihood and impact, assigns owners, and records treatment in the risk register.
• Compliance work maps laws, contracts, and frameworks to controls, then collects evidence that those controls operate.

Governance turns leadership decisions into documented authority, rules, and oversight routines.

• An information security policy states management's direction and names accountable roles.
• A risk committee charter defines membership, decision rights, quorum, and escalation thresholds.
• Meeting minutes and approved action logs show that leaders reviewed risks and assigned follow-up work.

They form different layers of direction, from mandatory intent to optional advice.

• A policy states a mandatory management rule, such as requiring access to follow least privilege.
• A standard gives mandatory measurable detail, such as requiring MFA for all privileged accounts.
• A procedure lists the steps to perform a task, such as the Okta access-review workflow.
• A guideline recommends a useful approach but allows justified alternatives, such as suggested password-manager practices.

I would place the measurable requirement in an access-control standard and link it to the broader access policy.

• The policy should state management's requirement for strong authentication and controlled privileged access.
• The standard should name the covered accounts, approved factors such as FIDO2 security keys, and any deadline.
• The implementation procedure should show how administrators enroll the factor and how reviewers verify enrollment.
• Any temporary deviation should reference an approved exception record rather than weakening the standard text.

A control objective states the result needed, while a control activity is the specific action used to achieve it.

• An objective might be that production access is limited to authorized personnel.
• A related activity could be a quarterly Okta access review approved by each application owner.
• The control narrative should connect the activity, frequency, owner, evidence, and population back to the objective.

A control owner is accountable for keeping the control defined, performed, evidenced, and corrected when it fails.

• The owner confirms the control narrative, frequency, systems in scope, and people who perform or review it.
• The owner provides evidence such as an Okta export and signed review record for the requested period.
• If testing finds an exception, the owner agrees on remediation, a due date, and any interim control.
• A GRC analyst coordinates and tests the record but does not silently become the owner of every control.

A manual control relies on a person, an automated control runs through configured technology, and a hybrid control combines both.

• A manager's quarterly review of an Okta access report is manual because the decision requires human judgment.
• An Okta rule that blocks access without MFA is automated, so testing should inspect its configuration, change history, and logs.
• A hybrid control may have AWS Config flag a public bucket and an analyst review and resolve the alert.
• Automation reduces repetitive effort but does not make a poorly scoped or misconfigured control effective.

Yes, but the control record should distinguish the separate activities and evidence supporting each function.

• An identity platform may prevent an unapproved role assignment through an approval workflow.
• The same platform may produce a report that detects dormant privileged accounts during a monthly review.
• I would document the approval log and review report separately so a tester can verify each purpose.
• Calling the whole platform a control is too broad because the configured activities are what auditors test.

Design effectiveness asks whether the control, if performed as written, can reasonably achieve its objective.

• I would check whether the control covers the correct systems, population, frequency, owner, and risk.
• A quarterly review of only employees is poorly designed if contractors also have production access.
• A walkthrough, control narrative, process diagram, and configured workflow can support the design assessment.
• Good design does not prove the activity actually happened during the audit period.

Operating effectiveness asks whether the control ran as designed, at the required frequency, throughout the tested period.

• For a quarterly access review, I would expect four completed reviews in a twelve-month period.
• Samples should show timely reviewer approval, the complete user population, and follow-up on identified access removals.
• A missed quarter or unsigned review is an operating exception even when the control design is sound.
• Testing results should state the period, sample, evidence examined, exception, and conclusion.

A SOC 2 examination is an independent attestation on controls relevant to selected Trust Services Criteria.

• Management defines the service organization's system, scope, commitments, and controls.
• A licensed CPA firm performs the examination under AICPA attestation standards and issues the report.
• The report is generally restricted-use material shared with customers and other parties who understand the service.
• SOC 2 is not a government certification or a guarantee that the service has no security weaknesses.

Type I addresses control design at a specified date, while Type II also tests operating effectiveness over a period.

• A Type I report can support an initial readiness milestone because its opinion is tied to an as-of date.
• A Type II report covers a stated review period, often several months, and includes tests of controls and results.
• Evidence for Type II must demonstrate recurring operation, such as every quarterly review within the period.
• Neither type automatically covers systems or criteria excluded from the report scope.

The categories are Security, Availability, Processing Integrity, Confidentiality, and Privacy.

• Security, also called the common criteria, is included in every SOC 2 examination.
• Availability addresses commitments for system operation, while Processing Integrity addresses complete, valid, accurate, timely, and authorized processing.
• Confidentiality concerns information designated as confidential, while Privacy concerns personal information across its lifecycle.
• The engagement scope should include only categories supported by actual customer commitments and system risks.

The system description, selected Trust Services Criteria, boundaries, commitments, and control inventory make the scope testable.

• The system description identifies services, infrastructure, software, people, procedures, data, and relevant subservice organizations.
• An in-scope inventory names the applications, cloud accounts, locations, and teams supporting the service.
• A criteria-to-control matrix shows which controls address each selected criterion.
• Scope changes should be versioned because adding a service or vendor can change the population and evidence requests.

An information security management system is the governed set of processes used to manage information security risk within a defined scope.

• The ISMS includes scope, leadership responsibilities, risk assessment, risk treatment, objectives, competence, documentation, and performance evaluation.
• Records such as the risk register, Statement of Applicability, internal audit, and management review show the system operating.
• Continual improvement means nonconformities and changing risks feed corrective actions and updates.
• The ISMS is broader than a folder of security policies or a list of technical controls.

Clauses 4 through 10 contain certifiable ISMS requirements, while Annex A provides a reference set of information security controls.

• The clauses cover context, leadership, planning, support, operation, performance evaluation, and improvement.
• Risk treatment determines which Annex A controls and other controls are necessary for the organization.
• An auditor can raise a nonconformity against a clause requirement even when no individual Annex A control has failed.
• Treating Annex A as the whole standard misses the management-system requirements.

The Statement of Applicability records every necessary control, whether from Annex A or another source, with its implementation status and selection rationale.

• Risk treatment is compared with Annex A to verify that no necessary control from the reference set was omitted.
• The statement also includes controls required by laws, contracts, other frameworks, or the organization's own design when Annex A is not sufficient.
• Every included control needs a justification, and every excluded Annex A control needs a defensible reason.
• Control identifiers, owners, and evidence links should be precise, and scope or risk changes should trigger review.

NIST CSF 2.0 organizes cybersecurity outcomes under Govern, Identify, Protect, Detect, Respond, and Recover.

• Govern sets organizational context, strategy, roles, policy, oversight, and supply-chain risk direction.
• Identify covers assets and risks, while Protect covers safeguards such as identity, data security, and awareness.
• Detect addresses finding events, Respond covers handling them, and Recover covers restoring operations and communicating recovery.
• A GRC analyst maps existing controls and evidence to outcomes rather than treating the functions as six project phases.

A Current Profile records prioritized outcomes the organization presently achieves, while a Target Profile records the desired state.

• The profile should reflect the organization's mission, threats, obligations, risk appetite, and available resources.
• Comparing the two produces gaps that can be assigned owners, priorities, budgets, and due dates.
• Evidence links should support Current Profile claims instead of relying only on workshop opinion.
• A profile is organization-specific and is not a certificate or universal maturity score.

PCI DSS scope starts with the cardholder data environment and connected or security-impacting systems, while the assessment path is set with the entity governing the compliance program, such as the acquirer or payment brand.

• The cardholder data environment includes people, processes, and technology that store, process, or transmit cardholder data or sensitive authentication data.
• Connected-to and security-impacting systems remain in scope unless effective segmentation and scope reduction are demonstrated.
• The governing compliance entity confirms SAQ eligibility and type or a ROC path, including whether a QSA or an Internal Security Assessor (ISA) may perform the assessment.
• The Attestation of Compliance records the result but does not replace the required evidence and testing.