Installs into .claude/skills of the current project.
Are you the author of Grc Analyst?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/aicodedecode-grc-analyst)
---
name: grc-analyst
description: Run governance, risk, and compliance operations — risk registers, control testing, policy lifecycle, and board reporting.
category: security
---
## Overview
GRC is the connective tissue of security management: governance sets direction, risk management prioritizes, and compliance verifies. The GRC analyst keeps this machinery running — maintaining the risk register, coordinating control testing, managing policy lifecycles, and translating it all into reporting that executives and boards can act on.
This skill covers the operating practice: risk assessment methodology, control programs, policy management, and the communication discipline that makes GRC influence decisions instead of producing shelfware.
GRC earns its seat by speaking the language of decisions: every risk gets an owner, a quantified impact range, and a clear choice (accept, mitigate, transfer, avoid) with a price tag. "High risk" without ownership and options is noise; "this risk costs X to mitigate, Y to accept, owned by Z" is governance.
## When to use
- Building or maturing the enterprise risk register.
- Coordinating control testing across frameworks.
- Managing the policy lifecycle (creation, review, exception, retirement).
- Preparing risk and compliance reporting for executives and the board.
- Running third-party risk assessments at scale.
## Core concepts
- **Risk = threat × vulnerability × impact, owned.** Every risk entry needs a named owner, assessed likelihood/impact, treatment decision, and review date. Ownerless risks are unowned outcomes.
- **Risk appetite and tolerance.** The board-level statement of how much risk the organization accepts — it turns "is this okay?" from opinion into policy. GRC operationalizes it into concrete thresholds.
- **Control testing program.** Design effectiveness + operating effectiveness, sampled on risk-based cadence, with evidence standards. Testing is what separates GRC from documentation.
- **Policy lifecycle.** Policies need owners, review dates (annual minimum), exception processes with expiry, and retirement — policy sprawl without lifecycle is shelfware accumulation.
- **Third-party risk.** Vendors inherit your risk profile: tiered assessments by criticality, continuous monitoring for critical vendors, and contract terms (audit rights, breach notification, data handling) set before signing.
- **Issue and exception management.** Findings, exceptions, and risk acceptances tracked in one system with owners and dates — the organization's memory of what it decided to live with.
- **Metrics that matter.** Control effectiveness trends, risk-acceptance aging, exception counts, policy compliance rates, and third-party risk posture — reported as trends with narrative, not raw counts.
- **Board reporting.** Quarterly, concise, decision-oriented: top risks with treatment status, control program health, notable incidents and lessons, and what needs board action. Boards govern; give them decisions, not dashboards.
- **Risk quantification ranges.** Replace single-point risk scores with ranges (best/expected/worst case) — it communicates uncertainty honestly and improves decision quality.
- **Control rationalization reviews.** Periodically ask which controls could be removed without increasing risk — control portfolios only grow unless pruned deliberately.
## Practical workflow
1. **Establish the risk register:** facilitate risk identification per business unit; assess consistently (use a fixed matrix); assign owners; record treatment decisions with dates. Review quarterly.
2. **Define risk appetite:** work with leadership to articulate appetite statements per risk category; translate into operational thresholds teams can apply.
3. **Run the control program:** unified controls mapped to frameworks; risk-based testing cadence; evidence repository; findings tracked to remediation with SLAs.
4. **Manage policies:** inventory all policies; assign owners and review dates; build the exception workflow (request, risk review, time-boxed approval, expiry enforcement).
5. **Operate third-party risk:** tier vendors by criticality and data access; assess accordingly (questionnaire → evidence review → on-site for critical); monitor continuously; track remediation.
6. **Report and improve:** monthly operational metrics to security leadership; quarterly risk posture to executives/board; annual program review asking "what did GRC change this year?"
### Quick wins
- Assign an owner and review date to every risk missing one this month
- Expire or re-justify every exception past its review date
- Produce a one-page top-risks brief for the next leadership meeting
### Sustaining the practice
- Refresh the risk register quarterly; retire or re-score stale risks
- Audit exception aging monthly — expired exceptions return to the queue automatically
- Re-assess critical vendors annually at minimum
- Benchmark the program against peers periodically to avoid insularity
### Metrics that prove it works
- % of risks with owners, current assessments, and treatment plans
- Control effectiveness trend (design + operating) by domain
- Exception count and average age; overdue remediation rate
- Board/executive action items arising from GRC reporting (influence, not just output)
## Common pitfalls
- **Risk registers as write-only.** Risks identified, scored, and never revisited. Quarterly review with owners or the register is decoration.
- **Compliance theater.** Passing audits while real risks go unmanaged. GRC must track risk reduction, not just audit outcomes.
- **Policy without enforcement.** Policies nobody reads, exceptions nobody expires. Tie policies to controls and measure adherence.
- **Third-party questionnaires as the program.** Sending SIG questionnaires with no validation, no tiering, and no follow-up is paperwork, not risk management.
- **Reporting data without decisions.** Fifty-slide decks of metrics with no "and therefore we should..." GRC reports should end with recommended actions.
- **No risk appetite.** Without appetite statements, every risk decision becomes a political negotiation. Get it written, even imperfectly.
- **GRC isolated from security operations.** Risk assessments disconnected from SOC/IR reality produce fantasy risk scores. Integrate operational data.
- **Exception permanence.** "Temporary" risk acceptances renewed indefinitely without re-assessment. Expiry must be enforced by process, not goodwill.
- **GRC as the 'department of no.'** Blocking business without offering risk-managed alternatives makes GRC the team everyone routes around. Offer options, not just objections.
- **Measuring GRC output instead of risk outcomes.** Policies published and audits passed are output; risk reduced and decisions improved are outcomes. Report outcomes.