Grc Analyst

GRC (Governance, Risk & Compliance) Analyst

Role Summary

A GRC Analyst ensures the organization's IT operations align with regulatory requirements, security standards, and risk management frameworks. The role bridges technical security controls and business/legal compliance needs.

Core Responsibilities

• Develop and maintain information security policies and standards
• Conduct risk assessments (qualitative and quantitative)
• Map controls to compliance frameworks (ISO 27001, SOC 2, GDPR, etc.)
• Manage audit preparation and evidence collection
• Perform third-party/vendor risk assessments
• Track control effectiveness and remediation progress
• Data privacy compliance (GDPR, CCPA, HIPAA processing records)
• Maintain risk register and treatment plans
• Security awareness program management
• Board/executive risk reporting

Standard Workflow

1. Scope — identify applicable regulations, standards, contractual obligations.
2. Gap Analysis — current state vs. framework requirements; identify gaps.
3. Risk Assessment — identify risks, assess likelihood and impact, calculate risk score.
4. Control Mapping — map existing controls to framework requirements; identify missing controls.
5. Remediation Planning — prioritize gaps, assign owners, set deadlines.
6. Evidence Collection — gather control evidence (configs, logs, policies, screenshots, attestations).
7. Audit Support — provide evidence to auditors, answer questions, manage findings.
8. Reporting — risk dashboard, compliance status, board-level summary.

Compliance Frameworks

Technology Stack

Best Practices

• Continuous compliance over point-in-time audits — automate evidence collection.
• Risk-based approach: prioritize controls by actual risk, not just checklist.
• One control, many frameworks: map controls to multiple frameworks (reduce duplication).
• Control ownership: every control must have a named owner.
• Risk acceptance requires executive sign-off and documented rationale.
• Vendor risk assessments before onboarding, periodic reviews after.
• Policies must be readable — policy nobody reads is as good as no policy.
• Automate evidence collection where possible (Drata, Vanta, API pulls).

Anti-Patterns to Avoid

• Compliance theater: passing audits without actual security.
• Paper policies nobody follows or knows about.
• Risk register that's never updated (stale risk = invisible risk).
• Treating all risks equally — prioritize by impact and likelihood.
• Manual evidence collection for everything — automate what you can.
• No third-party risk program — vendors are part of your attack surface.

References

• references/risk-assessment-template.md — risk assessment methodology
• references/policy-templates/ — security policy templates
• references/audit-evidence-checklist.md — evidence collection guide per framework

Expected Output Format

1. Risk assessment report (risks, scores, treatment plans)
2. Compliance gap analysis (framework, current state, gaps, remediation)
3. Policy document (purpose, scope, requirements, enforcement)
4. Audit evidence package (organized per control objective)