What a junior GRC analyst actually does

Risk assessments are the input to almost everything else GRC does: which controls to prioritize, which findings matter, what to tell leadership.

Annually at minimum, plus when launching new systems, vendors, products, or after a significant incident.

Expect to facilitate 2–6 risk workshops per quarter and own the risk register hygiene.

• • Asset inventory
• • Threat intelligence
• • Existing control list
• • Incident history
• • Business context interviews

• • Ranked list of risks
• • Inherent and residual ratings
• • Recommended treatments
• • Updates to the risk register

• • Risk assessment report
• • Risk register entries
• • Treatment plan

Without a register, risks live in slide decks and emails and nothing gets actioned.

Continuously — updates after every assessment, control change, or incident.

Often the analyst owns weekly register hygiene and a monthly aging report.

• • Risk assessment outputs
• • Incident reports
• • Audit findings
• • Control change tickets

• • Up-to-date register
• • Aging report
• • Trend metrics for leadership

• • Risk register (spreadsheet or GRC tool)
• • Risk acceptance memos

Risk ratings only make sense in this triple. 'A breach' isn't a risk; 'theft of customer PII via SQL injection on the public API' is.

Inside every risk assessment.

You'll partner with security engineering to translate scanner output into business-relevant risks.

• • CMDB / asset inventory
• • Data classification
• • Threat intel feeds
• • Vulnerability scanner output
• • Pen test reports

• • A-T-V statements ready to be scored

• • Asset register
• • Threat catalog
• • Vulnerability list

Drives prioritization. Without consistent scoring, the loudest stakeholder always 'wins.'

Every risk assessment and risk register update.

Expect to defend ratings in management review — be ready to point at the scale.

• • Scoring scale definitions
• • Historical incident data
• • Industry benchmarks

• • Numeric or qualitative ratings (e.g., 1–5)
• • Heat map placement

• • Risk scoring methodology
• • Risk register

Every risk needs an explicit decision and an owner. Defaulting to 'we'll fix it eventually' is not a treatment.

After scoring and before the risk hits the register as 'open.'

You won't sign acceptance memos as a junior, but you'll draft them and chase the signatures.

• • Risk rating
• • Cost of treatment
• • Business context
• • Risk appetite

• • Documented treatment decision
• • Risk acceptance memo if tolerating

• • Risk treatment plan
• • Risk acceptance memos signed by an appropriate executive

An undocumented control is an unauditable control. Auditors test what's written, not what people remember.

When a new control is implemented, when ownership changes, and at least annually.

Expect to interview 1–3 control owners per week during a SOC 2 audit window.

• • Process walkthroughs with control owners
• • Sample evidence
• • System screenshots

• • Control narrative
• • Updated control matrix entry

• • Control matrix
• • Process narratives
• • Evidence index

You don't want to run separate audits per framework. Mapping enables one control to cover many requirements.

When picking up a new framework or building a unified control framework (UCF).

The Secure Controls Framework (SCF) is your friend for cross-framework mapping work.

• • Existing control matrix
• • New framework requirements
• • Authoritative crosswalks (NIST, CSA CCM, SCF)

• • Mapping table
• • Gap list (requirements not yet covered)

• • Unified control matrix
• • Framework mapping spreadsheet

Policies set the floor for control expectations and are foundational evidence in every audit.

Initial program setup, annual review cycle, and when controls change materially.

You'll often be the first drafter and the librarian — owning the review cycle calendar.

• • Existing policy library
• • Framework requirements
• • Stakeholder interviews

• • Draft document
• • Reviewer comments
• • Approved policy with version history

• • Policy
• • Standards
• • Procedures
• • Approval record

Auditors don't take your word. Evidence is the currency of compliance work.

Year-round for Type II audits; spikes during fieldwork.

This is 30–60% of a junior SOC 2 analyst's life during audit fieldwork.

• • PBC list (Provided By Client)
• • Sample selections
• • Control matrix

• • Evidence package per control
• • Cross-reference index

• • Evidence index
• • Auditor request tracker

Without a coordinator, auditors interrupt engineers randomly and findings multiply.

Throughout fieldwork plus pre-kickoff and post-fieldwork phases.

Plan to be in the audit Slack channel 4–6 hours/day during fieldwork.

• • Audit plan
• • PBC list
• • Control owner contacts

• • Walkthrough schedule
• • Request tracker
• • Findings log

• • Auditor request tracker
• • Walkthrough notes

It's cheaper to find a broken control yourself than to take an exception in the final report.

Quarterly for mature programs; at minimum once before the audit window opens.

Often you run the testing while your manager reviews and signs off.

• • Control matrix
• • Sample populations
• • Test scripts

• • Internal audit report
• • Remediation list

• • Test scripts
• • Internal audit findings

Half the audit's success is set before fieldwork starts.

4–8 weeks before fieldwork.

You'll often own the PBC tracker end-to-end.

• • Last year's report
• • Updated control matrix
• • PBC list

• • Kickoff deck
• • Pre-populated PBC
• • Walkthrough schedule

• • Kickoff deck
• • Updated SSP / system description

Before you can certify or comply, you have to know what's missing.

Before adopting a new framework, after major org changes, or as a customer requirement.

A common 'first big project' for a new junior GRC analyst.

• • Framework requirements
• • Current control matrix
• • Process interviews

• • Gap list with severity and effort estimates
• • Remediation roadmap

• • Gap assessment report

Findings that linger become repeat findings, which become qualified opinions or failed certifications.

Continuously after any audit, assessment, or pen test.

Usually the analyst's responsibility, with escalation paths to a manager when items slip.

• • Findings
• • Owners
• • Target dates

• • Weekly aging report
• • Closure evidence

• • Remediation tracker
• • Closure memos

Reality demands exceptions. Undocumented exceptions are findings; documented ones are managed risks.

Whenever an exception is requested by a business unit or surfaced by an audit.

You'll often draft the exception, the engineering team will sign as owner, the CISO will sign as approver.

• • Exception request
• • Risk rating
• • Compensating controls

• • Approved exception record
• • Renewal calendar

• • Exception register
• • Approval memos

Missing a recertification deadline can be a contractual breach.

Always — typically a recurring weekly check.

A simple, high-leverage thing a junior analyst can own outright.

• • Certificate expiry dates
• • Customer contracts
• • Regulatory calendars

• • Compliance calendar
• • Status dashboard

• • Compliance tracker

Most breaches involve a third party. Your customers will ask how you manage yours.

Pre-contract for new vendors; annually or by tier thereafter.

Often run a queue of 5–20 active vendor reviews at any time.

• • Vendor list
• • Data shared
• • Service criticality
• • Vendor evidence (SOC 2, ISO cert)

• • Vendor risk rating
• • Approval/conditions/rejection
• • Re-assessment date

• • Vendor inventory
• • TPRM questionnaire
• • Risk assessment per vendor

Questionnaires are noisy. Skilled review is what extracts real risk signal.

Inside every TPRM review for a new or material vendor.

This is daily work in vendor-heavy orgs.

• • Completed questionnaire
• • Supporting evidence (SOC 2, pen test summary)

• • Findings list
• • Follow-up questions
• • Rating recommendation

• • Reviewed questionnaire with annotations

Issues scattered across emails and slides never close. A single tracker is the management view.

Continuously.

Often paired with remediation tracking under one role.

• • Audit findings
• • Self-identified issues
• • Incident lessons-learned

• • Issue log
• • Aging metrics

• • Issue log

If leadership doesn't see progress, the program loses funding.

Monthly for execs; quarterly for the board.

You'll often build the slides. Your manager will deliver them.

• • Risk register
• • Issue log
• • Training completion
• • Vendor inventory
• • Audit status

• • Exec dashboard
• • Board pack

• • Metrics standard
• • Dashboard

GRC sits at the boundary. Clear writing and calm meetings are the actual deliverable half the time.

Daily.

A career-defining skill — undervalued by juniors, prized by hiring managers.

• • Technical context
• • Audience expertise level
• • Decision needed

• • Briefing notes
• • Decision memos
• • Customer responses

• • Decision memo templates
• • Customer security review responses

Required by nearly every framework, and one of the best ROI investments in security.

At hire, annually, and when role/risk changes.

Usually a discrete chunk of the analyst's job — often 5–10% of time.

• • Training platform
• • HRIS feed
• • Phishing tool

• • Completion reports
• • Phishing campaign results

• • Training plan
• • Completion records
• • Sanction policy

Resilience is a board-level concern; the GRC team usually owns the program even if engineers run the technology.

Annual plan refresh, quarterly tests, post-incident reviews.

You may coordinate; SRE or IT operations runs the technical recovery.

• • Business impact analysis (BIA)
• • Recovery objectives (RTO/RPO)
• • Test results

• • Updated BCP
• • Test reports

• • BCP
• • BIA
• • Tabletop exercise notes

Auditors will ask for evidence of DR tests at least annually.

At least annually; ideally quarterly partial tests.

Coordinator and evidence collector, rarely the executor.

• • DR runbooks
• • Test schedule
• • RTO/RPO targets

• • DR test results
• • Updated runbooks

• • DR plan
• • Test reports

Incidents are inevitable. Good governance turns each one into a control improvement.

Plan review annually, tabletop quarterly, after-action immediately post-incident.

GRC supports IR; SecOps leads it.

• • IR plan
• • Post-incident reviews
• • Trend data

• • Updated IR plan
• • Lessons-learned tracker
• • Improvement actions

• • IR plan
• • PIR template
• • Improvement backlog

Auditors will ask: who owns this, when was it last reviewed, who approved it. A messy library = repeat findings.

Continuously.

A simple, high-trust thing for a junior to own from day one.

• • Document inventory
• • Review calendar

• • Up-to-date library
• • Review calendar
• • Approval records

• • Document index
• • Review schedule