GRC analyst

GRC is where security stops being a set of incidents and becomes a program. The analyst maintains the control framework, keeps the risk register honest, runs the policy lifecycle, handles third-party and privacy obligations, and produces the reporting a board reads. The craft is not paperwork for its own sake: it is making sure every accepted risk has a name against it and a date on it, and that the controls the organization claims to operate are the controls it operates. When an incident lands, GRC is what tells you whether the exposure was known and accepted, or simply missed.

• ·Maintain the control framework and the mapping between frameworks the business is held to.
• ·Run the risk register: rate, assign, date and re-review, rather than letting entries age quietly.
• ·Own the policy lifecycle — drafting, approval, exception handling and review cadence.
• ·Assess third parties on evidence, and track their remediation like your own.
• ·Coordinate audits: scope, evidence requests, owner wrangling and response to findings.
• ·Report the program's real state to leadership, including what is not working.

1. 09:00Register review
   Three risks hit their review date. Two owners want an extension; one accepted risk has quietly become a live incident and needs re-rating today.
2. 11:00Policy exception
   Engineering wants an exception to the MFA standard for a legacy service. Write it as a time-boxed exception with a compensating control, or reject it.
3. 13:00Third-party review
   A vendor's SOC 2 arrives with two carve-outs that matter. Map them to your own controls and decide what the business inherits.
4. 15:00Audit coordination
   Chase evidence for next week's fieldwork and pre-read the artifacts you know will get pushed back on.
5. 16:30Reporting
   Update the board pack. The honest slide is the one showing controls trending the wrong way, with an owner named.

• Risk register discipline

  Rate on impact and likelihood you can defend, assign an accountable owner, and force a decision date.

  cmp-201cmp-202cmp-301
• Framework mapping and control ownership

  One control tested once, satisfying several frameworks, without pretending the mappings are exact.

  cmp-101cmp-102cmp-103
• Incident governance

  Regulatory clocks, notification thresholds and the evidence an incident report has to carry.

  ir-101ir-201ir-301
• Security program literacy

  Understand what the technical teams are telling you well enough to challenge it, not just record it.

  sec-101sec-201sec-301

• GRC and risk register platforms
• Policy and exception tooling, evidence repositories
• Third-party risk questionnaires and attestation reports
• Frameworks: NIST CSF and SP 800-53, ISO 27001, SOC 2, PCI DSS, GDPR/DPA obligations

What separates a good analyst

• Never files a risk without a named owner and a date.
• Writes exceptions that expire instead of exceptions that become the standard.
• Can explain a control to an engineer in terms of what they must actually do.
• Reports the uncomfortable trend before someone else finds it.
• Treats an auditor's finding as information rather than as an attack.

• Senior GRC analyst — owns a framework or a business unit end to end.
• Risk manager — owns the register and the acceptance conversation with executives.
• Compliance or privacy lead — owns a regulatory relationship.
• Security program manager or CISO track — owns the whole program.