Roadmap
GRC Analyst
The professional who sits at the intersection of cybersecurity, business strategy, and regulatory compliance. Translates complex requirements into practical controls, maintains the risk register, supports audits, and ensures the organization can prove to customers, regulators, and partners that its security program is real.
OPTIMISTIC 12–18 months · REALISTIC 18–24 months
Stage 00
Computer & IT Fundamentals
GRC analysts assess technical environments they do not build. You need enough IT literacy to understand what you are governing and to be credible with the engineers you work with.
Computer Hardware & Systems
- CPU, RAM, storage — what these are and why they matter in risk context
- Servers vs workstations vs cloud instances — understanding the asset landscape
- Physical vs virtual machines — virtualization and its compliance implications
Number Systems
- Binary, hex — not required deeply but useful for reading technical documentation
How Operating Systems Work
- Kernel vs user space — why privilege separation matters for access control
- Processes and services — what runs on a system, audit trail relevance
- File systems — where data lives, encryption at rest relevance
- User accounts and permissions — NTFS ACLs, Linux permissions — the controls GRC governs
Networking Basics
- What a network is — clients, servers, firewalls, switches, routers
- IP addressing — private vs public, why network segmentation matters
- Ports and protocols — HTTP/HTTPS, SSH, RDP, DNS — what they do and why they appear in audit findings
- Firewall — what it does at a conceptual level, why network segmentation is a control
- VPN — how it works and why it matters for remote access controls
- Wi-Fi security — WPA2/WPA3, why open networks are a risk
Cloud Basics for GRC
- What cloud computing is — IaaS, PaaS, SaaS — and what each means for the shared responsibility model
- Major cloud providers — AWS, Azure, GCP — the environments GRC analysts commonly assess
- Shared responsibility model — where cloud provider responsibility ends and customer responsibility begins; this is the conceptual foundation of cloud compliance work
Software & Applications
- What a web application is — client, server, database — the architecture GRC assesses
- APIs — what they are and why they are an audit surface
- Software development lifecycle (SDLC) — why secure development controls exist
Resources
- Professor Messer CompTIA A+ (free YouTube)
- CS50 Introduction to Computing (Harvard, free)
- AWS Cloud Practitioner Essentials (free, AWS Skill Builder)
- TryHackMe Pre-Security path (free)
Stage 01
Security Fundamentals
GRC analysts govern security programs. You must understand what you are governing: the threats, vulnerabilities, controls, and frameworks that make up information security.
Core Security Concepts
- CIA Triad — Confidentiality, Integrity, Availability — every control maps back to protecting one or more
- AAA — Authentication, Authorization, Accounting — fundamental identity and access controls
- Threat vs vulnerability vs risk vs exposure — precise definitions that GRC analysts use daily
- Attack surface — why reducing it is a core governance objective
- Defense in depth — layered controls, why no single control is sufficient
- Least privilege — fundamental access control principle underlying IAM policies
- Separation of duties — preventing fraud and error through role design
- Need to know — information classification and access control alignment
Authentication & Identity Controls
- Password policies — length, complexity, rotation, MFA requirements
- Multi-factor authentication — types (something you know/have/are), why it is a required control in most frameworks
- Privileged access management (PAM) — why privileged accounts require elevated controls
- Single sign-on (SSO) — centralized identity, audit trail implications
- Identity lifecycle management — provisioning, deprovisioning, access reviews
- Federated identity — SAML, OIDC — enterprise identity provider integration
Cryptography for GRC
- Encryption at rest — protecting stored data, why it is required in most compliance frameworks
- Encryption in transit — TLS, why unencrypted communications are a finding
- Key management — who controls encryption keys, key rotation requirements
- Hashing — password storage, file integrity verification
- Certificate management — TLS certificates, expiry monitoring, compliance implications
- Why weak algorithms matter — MD5, SHA-1 deprecated status, compliance implications
Malware & Threats
- Malware types — ransomware, trojans, spyware, fileless — impact categories for risk register
- Phishing — the top initial access vector, why security awareness training is a required control
- Social engineering — business email compromise, insider threat
- DDoS — availability impact, DR/BCP relevance
- Supply chain attacks — third-party risk relevance
- APT — advanced persistent threat — long-term targeted intrusion, risk to sensitive data
Security Controls Framework
- Preventive controls — stopping incidents before they occur (firewalls, MFA, encryption)
- Detective controls — identifying incidents after they occur (logging, SIEM, IDS)
- Corrective controls — restoring systems after an incident (backups, IR plans, patch management)
- Administrative controls — policies, procedures, training, governance
- Technical controls — software and hardware enforcement mechanisms
- Physical controls — locks, cameras, badge access, environmental controls
- Control testing — how GRC analysts verify controls are operating effectively
Vulnerability Management
- CVE — Common Vulnerabilities and Exposures — the identifier standard
- CVSS v3.1 — base score, temporal score, environmental score — prioritization methodology
- Vulnerability scanning — Nessus, Qualys, Tenable — what they produce and how GRC uses the output
- Patch management — patching SLAs, tracking remediation, evidence collection
- Penetration testing — what it is, how it differs from vulnerability scanning, how GRC uses findings
Incident Response — GRC Perspective
- IR lifecycle — NIST SP 800-61 phases
- Notification obligations — regulatory breach notification timelines (GDPR 72 hours, HIPAA 60 days, SEC 4 business days)
- Tabletop exercises — testing IR plan effectiveness
- Business Continuity Planning (BCP) and Disaster Recovery (DR) — RTO/RPO, how they appear in compliance frameworks
Resources
Stage 02
Governance, Risk & Compliance Foundations
This is the core intellectual framework of the role, covering how governance, risk management, and compliance work as an integrated system.
Governance Fundamentals
- What governance is — defining authority, accountability, decision-making structures, and performance measurement
- Board and executive roles in information security governance — CISO, CRO, Board audit committee, executive steering committee
- Security policies — purpose, hierarchy (policy → standard → procedure → guideline), writing quality
- Policy lifecycle — drafting, review, approval, publication, training, enforcement, retirement
- Security awareness training — why it is a required control in almost every framework, adult learning principles, phishing simulation programs
- Organizational security structure — centralized vs decentralized GRC, three lines of defense model:
- First line — business units owning their risks
- Second line — risk and compliance functions
- Third line — internal audit providing independent assurance
- Information security program maturity — CMMI levels 1–5, maturity assessment methodology
- Metrics and KPIs — how GRC demonstrates program effectiveness to leadership
Risk Management Fundamentals
- Risk management lifecycle — identify → assess → treat → monitor → report
- Risk register — the central artifact of risk management: risk ID, description, owner, likelihood, impact, current controls, residual risk, treatment plan, due date
- Likelihood and impact — qualitative (High/Medium/Low), quantitative (dollar values), semi-quantitative (1–5 scales)
- Inherent vs residual risk — before and after controls are applied
- Risk treatment options — Accept, Avoid, Transfer (insurance), Mitigate (controls)
- Risk appetite and risk tolerance — organizational risk thresholds, board-set boundaries
- Risk owner — the person accountable for managing a specific risk
- Control owner — the person responsible for operating a specific control
- Key Risk Indicators (KRIs) — early warning metrics for emerging risks
- Risk quantification — FAIR (Factor Analysis of Information Risk) — monetizing risk for business decisions
- Threat modeling — STRIDE applied to GRC context, threat landscape assessment
Compliance Fundamentals
- What compliance is — demonstrating that required controls exist and operate effectively
- Gap analysis — comparing current state against framework requirements, identifying what is missing
- Control mapping — mapping a single control to multiple framework requirements (e.g., MFA satisfies SOC 2 CC6.1, ISO 27001 A.9.4.2, NIST CSF PR.AC-7)
- Evidence collection — what constitutes valid audit evidence (screenshots, logs, configurations, approvals)
- Audit readiness — maintaining evidence throughout the year, not just at audit time
- Finding vs observation vs recommendation — audit terminology distinctions
- Remediation tracking — assigning owners, due dates, and verification to audit findings
- Continuous compliance monitoring — automated evidence collection, always-on compliance posture
The Three GRC Disciplines Integrated
- How governance sets the framework and accountability structure
- How risk management identifies and prioritizes what to protect
- How compliance demonstrates that protections are in place and working
- GRC as a business enabler — compliance as a sales tool (SOC 2 report enables enterprise deals), risk management as cost reduction
Resources
- OCEG GRC Illustrated series (free downloads)
- ISACA GRC resources (free member content)
- NIST Risk Management Framework documentation (free)
Stage 03
Compliance Frameworks — Deep Knowledge
Framework mastery is the core technical skill of GRC. Most GRC analysts need to know at least three frameworks deeply.
SOC 2 (Service Organization Control 2)
- Who it applies to — service organizations (SaaS, cloud providers, managed service providers) serving other businesses
- Trust Services Criteria (TSC):
- CC — Common Criteria (Security) — the required criteria; all 33 CC controls
- A — Availability — uptime commitments
- PI — Processing Integrity — complete, valid, accurate, timely processing
- C — Confidentiality — protecting confidential information
- P — Privacy — handling personal information
- Type I vs Type II:
- Type I — point-in-time assessment of design adequacy (are the right controls in place?)
- Type II — period of time (3–12 months) assessment of operating effectiveness (are controls working consistently?)
- AICPA TSC structure — each criterion has points of focus (POFs) and suggested controls
- Key controls in CC:
- CC1 — Control Environment (tone at the top, org structure)
- CC2 — Communication and Information
- CC3 — Risk Assessment
- CC4 — Monitoring
- CC5 — Control Activities
- CC6 — Logical and Physical Access Controls (the most tested — MFA, access reviews, encryption)
- CC7 — System Operations (monitoring, incident response)
- CC8 — Change Management
- CC9 — Risk Mitigation (vendor management, BCP)
- SOC 2 audit process — readiness assessment → gap remediation → auditor selection → evidence collection → auditor fieldwork → report issuance
- Complementary User Entity Controls (CUECs) — controls customers must implement
- Subservice organizations — fourth-party risk in SOC 2 context
- Continuous monitoring for SOC 2 — Drata, Vanta, Secureframe automating evidence collection
ISO 27001
- Who it applies to — any organization seeking internationally recognized ISMS certification
- ISMS (Information Security Management System) — the governance structure ISO 27001 creates
- ISO 27001:2022 structure:
- Clauses 4–10 — mandatory management requirements (context, leadership, planning, support, operation, evaluation, improvement)
- Annex A — 93 controls across 4 themes (Organizational, People, Physical, Technological)
- Scope statement — defining what is in and out of ISMS scope
- Statement of Applicability (SoA) — documenting which Annex A controls apply and why
- Risk treatment plan — the document connecting risk assessment to control selection
- Internal audit — required by Clause 9.2, independent assessment of ISMS
- Management review — Clause 9.3, leadership review of ISMS performance
- Certification process — Stage 1 audit (documentation review) → Stage 2 audit (implementation verification) → certification issued → surveillance audits (years 1 & 2) → recertification audit (year 3)
- ISO 27001 vs SOC 2 — ISO 27001 is a certification with prescriptive management requirements; SOC 2 is an attestation report focused on trust services
NIST Cybersecurity Framework (CSF) 2.0
- Who it applies to — US federal agencies (mandatory via FISMA), broadly adopted by private sector
- Six functions:
- Govern (new in 2.0) — organizational context, risk management strategy, supply chain risk
- Identify — asset management, business environment, risk assessment
- Protect — access control, awareness training, data security, protective technology
- Detect — anomalies, continuous monitoring, detection processes
- Respond — response planning, communications, analysis, mitigation
- Recover — recovery planning, improvements, communications
- Profiles — current state vs target state gap analysis
- Tiers — organizational risk management maturity (1–4)
- NIST CSF as a communication tool — translating technical security to business risk language
- Mapping NIST CSF to other frameworks — most GRC work involves multi-framework mapping
NIST Risk Management Framework (RMF)
- Who it applies to — US federal information systems (mandatory), defense contractors, FedRAMP
- Seven steps — Prepare → Categorize → Select → Implement → Assess → Authorize → Monitor
- FIPS 199 — system categorization (Low/Moderate/High) based on CIA impact
- NIST SP 800-53 — control catalog, over 1,000 controls across 20 families
- Authorization to Operate (ATO) — the formal approval to run a federal information system
- Continuous Monitoring — ongoing assessment and reporting of security status
PCI-DSS v4.0
- Who it applies to — any organization that stores, processes, or transmits cardholder data
- Cardholder Data Environment (CDE) — the scoped environment containing payment data
- Six goals, twelve requirements:
- Goal 1 (Req 1–2): Build and maintain a secure network
- Goal 2 (Req 3–4): Protect cardholder data (encryption at rest and in transit)
- Goal 3 (Req 5–6): Maintain vulnerability management program
- Goal 4 (Req 7–9): Implement strong access control
- Goal 5 (Req 10–11): Monitor and test networks
- Goal 6 (Req 12): Maintain information security policy
- SAQ (Self-Assessment Questionnaire) — for merchants not using QSA
- QSA (Qualified Security Assessor) — required for Level 1 merchants
- PCI DSS v4.0 changes — customized approach, enhanced authentication requirements, scripting controls
- Scope reduction — segmentation to minimize CDE scope
HIPAA (Health Insurance Portability and Accountability Act)
- Who it applies to — covered entities (healthcare providers, health plans, clearinghouses) and business associates
- Three rules:
- Privacy Rule — protects PHI (Protected Health Information), use and disclosure limitations, patient rights
- Security Rule — administrative, physical, technical safeguards for ePHI
- Breach Notification Rule — 60-day notification to HHS, individuals, and media (if 500+ affected)
- PHI vs ePHI — all 18 HIPAA identifiers
- Business Associate Agreement (BAA) — required contract with vendors handling PHI
- Technical safeguards:
- Access controls — unique user IDs, emergency access procedures, automatic logoff, encryption
- Audit controls — hardware, software, and procedural mechanisms to record and examine activity
- Integrity controls — authentication mechanisms to protect ePHI from unauthorized alteration
- Transmission security — encryption for ePHI in transit
- HITECH Act — increased penalties ($100 to $1.9M per violation category per year), extended to business associates
- OCR (Office for Civil Rights) — enforcement, audit program
- HIPAA Security Risk Assessment — required annually, comprehensive
GDPR (General Data Protection Regulation)
- Who it applies to — any organization processing personal data of EU/EEA residents, regardless of where the organization is located
- Six lawful bases for processing — consent, contract, legal obligation, vital interests, public task, legitimate interests
- Eight data subject rights — access, rectification, erasure (right to be forgotten), restriction, portability, object, automated decision-making, information
- Privacy by Design and by Default — security and privacy built into systems from inception
- Data Protection Impact Assessment (DPIA) — required for high-risk processing
- Data Protection Officer (DPO) — required for public authorities, large-scale processing
- Breach notification — 72 hours to supervisory authority, without undue delay to data subjects if high risk
- Lawful basis for international data transfers — adequacy decisions, Standard Contractual Clauses (SCCs), Binding Corporate Rules (BCRs)
- Cross-border data transfer after Schrems II — invalidation of Privacy Shield, EU-US Data Privacy Framework
- GDPR fines — up to €20M or 4% of global annual turnover, whichever is higher
- GDPR vs CCPA — EU vs California privacy law comparison
SOX (Sarbanes-Oxley Act) — IT GRC Context
- Who it applies to — publicly traded companies listed on US exchanges
- Section 302 — CEO/CFO certification of financial report accuracy
- Section 404 — management assessment of internal controls over financial reporting (ICFR)
- IT General Controls (ITGCs) — the controls IT auditors test for SOX:
- Access to programs and data — segregation of duties, user access reviews
- Program change management — change control, approval processes
- Computer operations — backup and recovery, incident management
- IT risk assessment and program development — SDLC controls
- COSO framework — framework used for ICFR evaluation
- External auditor reliance — how external auditors rely on internal audit's ITGC testing
CMMC (Cybersecurity Maturity Model Certification)
- Who it applies to — US Department of Defense contractors and subcontractors
- CMMC 2.0 levels — Level 1 (Foundational), Level 2 (Advanced), Level 3 (Expert)
- NIST SP 800-171 — 110 practices for protecting Controlled Unclassified Information (CUI)
- Level 2 assessment — annual self-assessment or triennial C3PAO assessment
- System Security Plan (SSP) and Plan of Action & Milestones (POA&M)
Emerging Frameworks
- DORA (Digital Operational Resilience Act) — EU financial sector ICT risk management, enforceable from January 2025
- NIS2 Directive — EU network and information systems security, critical infrastructure sectors
- EU AI Act — AI risk categorization, prohibited AI practices, compliance requirements
- SEC Cybersecurity Disclosure Rules — material incident disclosure within 4 business days, annual risk management disclosure
Resources
- AICPA TSC documentation (free)
- ISO 27001:2022 standard (paid, ~$200)
- NIST CSF documentation (nist.gov, free)
- NIST SP 800-53 (free)
- PCI Security Standards Council documentation (free)
- HHS HIPAA guidance (hhs.gov, free)
- GDPR text (eur-lex.europa.eu, free)
- Drata/Vanta/Secureframe blogs (free framework guides)
Stage 04
Risk Management Practice
Risk assessment and risk register management are the daily work of a GRC analyst. These are applied skills, not just concepts.
Risk Assessment Methodology
- Qualitative risk assessment:
- Likelihood scale — Rare (1), Unlikely (2), Possible (3), Likely (4), Almost Certain (5)
- Impact scale — Negligible (1), Minor (2), Moderate (3), Major (4), Catastrophic (5)
- Risk score = Likelihood × Impact
- Risk matrix — plotting risks on a 5×5 grid for prioritization
- Limitations — subjectivity, inconsistency across assessors
- Quantitative risk assessment:
- Asset Value (AV) — the value of what is being protected
- Exposure Factor (EF) — percentage of asset value lost if threat is realized
- Single Loss Expectancy (SLE) = AV × EF
- Annual Rate of Occurrence (ARO) — how many times per year the threat is expected
- Annualized Loss Expectancy (ALE) = SLE × ARO
- FAIR (Factor Analysis of Information Risk) — probabilistic quantitative methodology
- Limitations — requires accurate threat frequency and asset value data
- Semi-quantitative — combining numerical scales with descriptive categories
- Threat identification sources — threat intelligence, industry reports, past incidents, MITRE ATT&CK, ENISA threat landscape
Risk Register Management
- Risk register fields:
- Risk ID — unique identifier
- Risk description — clear, specific statement of what could go wrong
- Risk category — strategic, operational, compliance, financial, reputational
- Threat source — who or what could cause the risk
- Threat event — what they would do
- Vulnerability — what weakness enables the threat
- Likelihood (inherent) — before controls
- Impact (inherent) — before controls
- Inherent risk score
- Existing controls — what mitigates the risk today
- Control effectiveness — how well current controls reduce likelihood/impact
- Residual likelihood, residual impact, residual risk score
- Risk owner — accountable person
- Treatment plan — what will be done
- Target date — when treatment will be complete
- Residual risk after treatment
- Risk acceptance — formal documented decision if accepted
- Risk register maintenance — quarterly reviews, new risk identification, closure of addressed risks
- Risk reporting — executive dashboard, board risk report, trend analysis
Third-Party Risk Management (TPRM)
- Why third-party risk matters — SolarWinds, Log4Shell, vendor access to your environment and data
- Third-party risk lifecycle:
- Identification — mapping all vendors, categorizing by data access and criticality
- Assessment — vendor questionnaires, SOC 2 review, penetration test summary review
- Onboarding — contract terms (data processing agreements, security requirements, right to audit)
- Monitoring — annual reassessment, continuous monitoring, incident notification requirements
- Offboarding — data return/destruction, access revocation
- Vendor questionnaires — SIG (Standardized Information Gathering), CAIQ (Consensus Assessment Initiative Questionnaire), custom questionnaires
- SOC 2 report review — how to read a Type II report, evaluating exceptions, reading complementary user entity controls
- Vendor tiering — Tier 1 (critical, full assessment), Tier 2 (significant, reduced assessment), Tier 3 (minimal risk, questionnaire only)
- Fourth-party risk — your vendor's vendors, subservice organization disclosure in SOC 2
Business Continuity and Disaster Recovery (BCP/DR) — GRC Perspective
- BCP vs DR — BCP is the broader plan for maintaining business operations; DR focuses specifically on IT systems recovery
- RTO (Recovery Time Objective) — maximum acceptable downtime
- RPO (Recovery Point Objective) — maximum acceptable data loss window
- Business Impact Analysis (BIA) — identifying critical functions and their recovery requirements
- BCP/DR plan documentation — GRC maintains and tests these plans
- Tabletop exercises — structured discussion-based simulations, GRC facilitates
- BCP/DR in compliance frameworks — SOC 2 A criteria, ISO 27001 A.17, NIST SP 800-34
Resources
- FAIR Institute resources (fairinstitute.org, free)
- ISACA Risk IT framework (free summary)
- NIST SP 800-30 Risk Assessment Guide (free)
- Shared Assessments SIG questionnaire (free overview)
Stage 05
Audit Support & Control Testing
GRC analysts are the primary interface with external auditors and own the evidence collection process.
Audit Fundamentals
- Types of audits:
- Internal audit — independent assurance function within the organization
- External audit — third-party assurance (SOC 2 auditors, ISO 27001 certification bodies)
- Regulatory examination — regulator-conducted (OCR HIPAA audits, OCC bank exams)
- Penetration test — technical security assessment, feeds GRC findings
- Audit planning — scope definition, risk-based approach, audit program development
- Audit evidence — what constitutes valid evidence:
- Sufficient — enough evidence to support the conclusion
- Appropriate — relevant, reliable, from a credible source
- Types — observation, inquiry, inspection of documents, re-performance
- Audit sampling — statistical vs non-statistical, sample size determination
- CAATs (Computer-Assisted Audit Techniques) — using data analytics tools during audits
Control Testing
- Design vs operating effectiveness:
- Design — is the control designed correctly to address the risk?
- Operating effectiveness — is the control actually working as designed over the period?
- Control testing methods:
- Inquiry — asking control owners about the control (lowest assurance)
- Observation — watching the control being performed
- Inspection — reviewing documentation, logs, reports, screenshots
- Re-performance — independently executing the control procedure
- Testing frequency — compensating for automated vs manual controls
- Evidence quality — screen captures, system-generated logs, signed approvals, configuration exports
- Population vs sample — when to test all items vs a sample
Evidence Collection & Management
- Common evidence types:
- Screenshots with timestamps — UI-based evidence
- Exported reports — access review reports, vulnerability scan reports, log excerpts
- Configuration exports — firewall rules, IAM policy exports, encryption settings
- Signed approvals — email threads, ticketing system approvals, DocuSign audit trails
- Training completion records — LMS exports showing completion dates and scores
- Vendor documents — vendor SOC 2 reports, penetration test summaries
- Evidence naming conventions — consistent naming for audit packages
- Evidence repository — organizing evidence by control, framework requirement, and testing period
- Audit management tools — managing requests, evidence submission, finding tracking
Audit Finding Management
- Finding severity — Critical, High, Medium, Low, Informational
- Finding structure — condition (what is), criteria (what should be), cause (why), effect (so what), recommendation
- Management response — agreeing or disagreeing with finding, providing remediation plan
- Remediation tracking — assigning owners, due dates, evidence of completion
- Finding closure — providing evidence that remediation was completed, auditor verification
Resources
- IIA (Institute of Internal Auditors) practice guides (free member content)
- ISACA IS Audit Standards (free)
- AICPA SOC 2 criteria documentation (free)
Stage 06
Policy Writing & Security Documentation
GRC analysts write and maintain the documentation that proves the security program is real. Policy quality directly impacts audit outcomes.
Policy Hierarchy
- Policy — high-level mandatory statement of intent (what must be done, why)
- Standard — specific mandatory requirements derived from policy (measurable thresholds)
- Procedure — step-by-step instructions for implementing a standard
- Guideline — non-mandatory recommendations and best practices
- Baseline — minimum security configuration requirements for systems
Writing Security Policies
- Policy components — purpose, scope, policy statement, roles and responsibilities, enforcement, exceptions, review schedule
- Policy tone — authoritative but clear, avoid jargon where possible
- Common required policies:
- Acceptable Use Policy (AUP)
- Access Control Policy
- Change Management Policy
- Incident Response Policy
- Data Classification Policy
- Data Retention and Disposal Policy
- Encryption Policy
- Business Continuity Policy
- Vendor Management Policy
- Remote Work / BYOD Policy
- Security Awareness Training Policy
- Vulnerability Management Policy
- Logging and Monitoring Policy
- Policy approval process — owner, reviewer, approver, board/executive signoff
- Policy exceptions — formal exception process, compensating controls, time-limited approval
- Policy reviews — annual review requirement in most frameworks
Data Classification
- Classification levels — Public, Internal, Confidential, Restricted (vary by organization)
- Labeling requirements — how classification is applied to documents, systems, emails
- Handling requirements — each level has different storage, transmission, and disposal requirements
- Data inventory — knowing what data exists, where it lives, who has access
Procedure Writing
- Procedure format — numbered steps, decision points, roles, screenshots where helpful
- Procedures for common GRC activities:
- Access review procedure
- User provisioning/deprovisioning procedure
- Incident response procedure
- Change request procedure
- Backup and recovery procedure
- Vendor onboarding procedure
Resources
- SANS Security Policy Templates (sans.org/information-security-policy/, free templates)
- NIST SP 800-12 Introduction to Information Security (free)
- ISO/IEC 27002:2022 guidance (paid)
Stage 07
GRC Tools & Platforms
GRC platforms automate evidence collection, control testing, and compliance tracking. Familiarity with at least one is listed in most GRC job postings.
Compliance Automation Platforms (for SaaS/Tech Companies)
- Vanta — automated SOC 2, ISO 27001, HIPAA, GDPR compliance:
- Integrations — AWS, GCP, Azure, GitHub, Okta, GSuite, Slack, Jira, HR systems
- Automated tests — checking configuration against control requirements
- Evidence collection — automatic screenshot and log collection
- Trust center — customer-facing compliance documentation portal
- Common in startup and mid-market tech companies
- Drata — similar to Vanta, strong automation and integrations
- Secureframe — similar capabilities, strong HIPAA and CMMC support
- Sprinto — similar, strong in mid-market SaaS
- OneTrust — broader GRC platform, strong privacy and third-party risk capabilities
Enterprise GRC Platforms
- ServiceNow GRC — large enterprise standard:
- Risk Management application — risk register, risk assessment, heat maps
- Compliance Management — control library, testing schedules, evidence management
- Audit Management — audit planning, fieldwork, finding management
- Policy and Compliance — policy repository, attestation workflows
- Vendor Risk Management — supplier assessments, questionnaire automation
- Integration with IT service management — change management, incident management
- RSA Archer — enterprise GRC platform, common in large regulated organizations
- MetricStream — GRC platform common in financial services
- LogicGate — modern cloud-native GRC platform
- eramba — open-source GRC platform (free tier)
Risk Quantification Tools
- FAIR Toolkits — implementing FAIR methodology
- RiskLens — commercial FAIR quantification platform
- Excel/Sheets — most GRC analysts build risk registers in spreadsheets
Vendor Risk Management Platforms
- BitSight — continuous security ratings for vendors
- SecurityScorecard — vendor security ratings, portfolio monitoring
- Prevalent — vendor risk management lifecycle platform
- ProcessUnity — vendor risk management with questionnaire automation
Vulnerability Management / Scanning (GRC Context)
- Nessus / Tenable — vulnerability scanner output used for risk register and compliance evidence
- Qualys — cloud-based vulnerability management
- Rapid7 InsightVM — vulnerability management with risk prioritization
- Understanding scan reports — reading findings, severity, remediation tracking
Security Awareness Training
- KnowBe4 — most widely deployed, phishing simulation, compliance training modules
- Proofpoint Security Awareness Training — email security focused
- Curricula — modern animated content, compliance-ready training
- Training completion tracking — LMS reports as compliance evidence
Resources
- Vanta documentation (free)
- ServiceNow GRC product documentation (free)
- eramba community edition (free)
- OCEG GRC tooling guides (free)
Stage 08
Vendor & Third-Party Risk Assessment
Third-party risk is one of the highest-value GRC functions. Understanding how to assess vendors and interpret their compliance documentation is a core daily skill.
Vendor Questionnaires
- SIG (Standardized Information Gathering) Questionnaire — Shared Assessments standard:
- 18 domains covering the full security program
- SIG Core — full 1,400+ questions
- SIG Lite — abbreviated 130-question version
- Completing SIGs for your organization's incoming assessments
- Reviewing SIGs from vendors
- CAIQ (Consensus Assessment Initiative Questionnaire) — Cloud Security Alliance, cloud-focused
- VSA (Vendor Security Alliance) questionnaire
- Custom questionnaires — building organization-specific assessments
Reading SOC 2 Reports
- Report sections:
- Section I — Management assertion
- Section II — Independent auditor's report
- Section III — System description — what the service organization does
- Section IV — Trust Services Criteria, controls, and test results
- What to look for:
- Scope of the report — does it cover what you care about?
- Period of coverage — how recent is the Type II?
- Exceptions — any qualified opinions or noted exceptions?
- Complementary User Entity Controls — what you must implement
- Subservice organizations — who does the vendor rely on?
- Type I vs Type II evaluation — Type I is weaker assurance; Type II with no exceptions is ideal
Penetration Test Review
- Reading pentest executive summaries — scope, methodology, critical findings, trend vs prior period
- Evaluating finding severity and remediation status
- Using pentest findings in vendor risk assessment
- Annual pentest requirement in SOC 2, ISO 27001, PCI-DSS — verifying completion as evidence
Continuous Vendor Monitoring
- Security ratings services — BitSight, SecurityScorecard — external scan-based risk signals
- Certificate expiry monitoring — public-facing TLS certificate health
- Breach monitoring — tracking vendor data breaches using HaveIBeenPwned, DarkOwl
- Annual reassessment — scheduling and tracking periodic reassessments
Resources
- Shared Assessments SIG overview (free)
- CSA CAIQ (free download)
- SOC 2 reading guides (AICPA, free)
- BitSight free tier
Stage 09
Communication, Reporting & Stakeholder Management
GRC analysts must translate technical findings into business risk language. Written and verbal communication is tested in interviews and determines career progression.
Executive Reporting
- Risk dashboard — heat maps, trend lines, open finding counts, metrics
- Board-level security report — business impact language, no technical jargon
- Compliance status report — framework coverage percentage, outstanding gaps, upcoming audit timelines
- KPI and KRI reporting — mean time to patch, access review completion rate, training completion rate, open critical findings age
- Making the business case — translating risk scores into dollar values and reputational risk
Stakeholder Communication
- Engineering teams — explaining why a control is required, finding compromise on implementation
- Legal teams — regulatory interpretation, breach notification decisions
- HR teams — policy exceptions, employee disciplinary actions for security violations
- Finance teams — risk quantification, compliance cost-benefit analysis
- Executives — strategic risk posture, compliance program maturity
- External auditors — professional, organized, evidence-based communication
Responding to Customer Security Questionnaires
- Customer trust questionnaires — completing security assessments sent by prospective enterprise customers
- Standard questions — encryption, access controls, SDLC security, vulnerability management, incident response, data handling
- Maintaining a master answer library — pre-approved responses for common questions
- Trust portal — sharing SOC 2 report, penetration test summary, policies with customers under NDA
- GRC as a sales enabler — compliance reduces sales friction with enterprise customers
Writing Clear Audit Findings
- SMART recommendations — Specific, Measurable, Achievable, Relevant, Time-bound
- Root cause analysis — addressing cause, not just symptom
- Management response — professional framing of remediation commitment
- Escalation decisions — when to escalate unresolved findings to executive level
Resources
- ISACA CISM content on reporting (free sample)
- OCEG communication guides (free)
Stage 10
Hands-On Practice & Portfolio
Practice Activities
- Conduct a mock SOC 2 readiness assessment — take the AICPA TSC criteria and assess a personal project or open-source tool against them
- Build a sample risk register — identify 10–15 risks for a hypothetical SaaS company with likelihood, impact, controls, and treatment plans
- Complete a vendor assessment — review a public SOC 2 report from a vendor (many tech companies publish these in their trust centers)
- Write sample security policies — draft an acceptable use policy, access control policy, and data classification policy
- Map controls to multiple frameworks — take 10 controls and map them to SOC 2, ISO 27001, NIST CSF, and HIPAA simultaneously
- Set up eramba community edition — free GRC platform for hands-on practice
- Complete vendor questionnaires — practice completing SIG Lite responses for a hypothetical organization
GRC Platforms to Learn
- Vanta — free trial available; explore automated evidence collection and control mapping
- eramba community edition — free, open-source, full GRC platform
- ServiceNow developer instance — free developer account at developer.servicenow.com for GRC module exploration
What to Document on LabList
- Mock risk register — documented risk assessment for a hypothetical or real project
- Sample policy portfolio — 2–3 security policies written to framework requirements
- Framework mapping exercise — control mapped to 3+ frameworks with explanation
- SOC 2 report review writeup — documented analysis of a publicly available SOC 2 report
- GRC tool experience — screenshots and notes from eramba or Vanta trial
- Cert progression — Security+ → GRCP or CRISC documented with context
FAQ
Common questions
How long does it take to become a GRC Analyst?
12–18 months optimistic at 20–25 hours/week, 18–24 months realistic. GRC is one of the most accessible security paths because it rewards judgment, writing skill, and framework knowledge over deep technical implementation. Career-changers from audit, compliance, project management, and policy backgrounds transition rapidly. The role is in genuine demand — search interest for GRC Analyst roles increased over 1000% in five years.
Which certifications matter for GRC?
Security+ as foundation. CRISC if risk management is central. CISA for audit-heavy roles. CISSP for senior GRC positions. ISO 27001 Lead Implementer or Lead Auditor for ISO-focused organizations. CIPP/E or CIPP/US for privacy-heavy GRC. Big Four consulting firms recruit aggressively for GRC practices and often sponsor cert progression. Cert + 1–2 years experience opens doors that pure self-study doesn't.
Do I need a specific degree?
No. GRC welcomes career-changers from law, accounting, audit, project management, and operations. What you do need: strong professional writing (policies, reports, audit responses), framework fluency (NIST CSF, ISO 27001, SOC 2 at minimum), and stakeholder management instincts. The role is conversation-heavy — auditors, business owners, executives, customers responding to security questionnaires. If you dislike writing or meetings, GRC is the wrong path.
What separates a hired GRC Analyst?
Mock control mappings and policy writing samples. Build a public portfolio with: a SOC 2 control matrix mapping 30–40 controls across the Trust Services Criteria, an ISO 27001 statement of applicability, a policy you wrote (acceptable use, data classification, incident response), and a sample audit response. Most GRC candidates have certs and theoretical knowledge; few have demonstrated artifacts. Stricter regulations (GDPR, DORA, NIS2, AI Act, CMMC) drive sustained demand.