A GRC analyst helps an organisation prove that its security is managed properly: they keep track of risks, check that controls work, keep policies current, and gather the evidence that auditors, regulators and customers ask for. GRC stands for governance, risk and compliance, and it is one of the few cybersecurity paths where strong writing, organisation and business sense count as much as technical depth.
If you like structure, documents and understanding how a whole business works, this is a realistic way into security. Here is what the job involves, what you need to know, sample work you can practise this week, and how people get their first role.
What does GRC mean in cybersecurity?
The three words describe three linked jobs:
- Governance: deciding who is responsible for security and how decisions get made. Policies, standards, roles, committees and reporting to leadership.
- Risk: identifying what could go wrong, how likely it is and how bad it would be, then deciding what to do about it.
- Compliance: showing that the organisation meets the requirements it is subject to, whether laws, regulations, contracts or standards it has chosen to follow.
A penetration tester finds a weakness in one system. A SOC analyst spots an attack in progress. A GRC analyst asks whether the organisation as a whole has the right controls, whether they are working, and whether anyone can prove it.
What does a GRC analyst do day to day?
Responsibilities vary by employer, but a typical job description includes most of these:
- Maintaining the risk register: recording risks, scoring them, tracking owners and treatment plans.
- Testing controls: checking that what the policy says happens actually happens, and collecting evidence.
- Writing and reviewing policies, standards and procedures.
- Supporting internal and external audits (ISO 27001 certification audits, SOC 2 examinations, regulatory inspections): preparing evidence, answering auditor queries, tracking findings to closure.
- Third-party risk: sending and reviewing security questionnaires to suppliers, assessing their answers and evidence.
- Answering customer security questionnaires (common in fintech and SaaS companies selling to larger businesses).
- Running or supporting security awareness activity.
- Reporting metrics and status to management.
Here is an illustrative week at a fictional company, Acme Fintech, to make that concrete:
| Day | What the GRC analyst works on |
|---|---|
| Monday | Quarterly access review: export user lists from the payments platform, send them to managers to confirm, chase replies |
| Tuesday | A partner bank’s 120-line security questionnaire; pull answers from existing policies and flag gaps |
| Wednesday | Risk workshop with engineering about a new cloud service; add two risks to the register |
| Thursday | Gather evidence for the ISO 27001 surveillance audit: backup test records, change approvals, training completion |
| Friday | Update the information security policy after a regulatory change; send it for approval |
Notice how much of it is communication. GRC analysts spend their days asking engineers, managers and suppliers for things, and turning the replies into something an auditor or executive can rely on.
Which frameworks does a GRC analyst need to know?
You do not need to memorise every framework. You need to understand a few well and know what the others are for.
| Framework or law | What it is | Why it matters to you |
|---|---|---|
| ISO/IEC 27001 | International standard for an information security management system (ISMS); organisations can be certified against it | The most common framework you will work with outside the US |
| SOC 2 | An attestation report by an independent CPA firm against the AICPA’s Trust Services Criteria | Very common for SaaS and fintech companies selling to US customers. It is a report, not a certificate |
| NIST CSF 2.0 | A voluntary framework organised into six functions: Govern, Identify, Protect, Detect, Respond, Recover | A clear structure for describing and improving a security programme |
| Nigeria Data Protection Act 2023 | Nigeria’s data protection law, overseen by the Nigeria Data Protection Commission | Essential for anyone working with personal data in Nigeria |
| GDPR / UK GDPR | EU and UK data protection law | Relevant for organisations serving European or UK customers |
| PCI DSS | Card industry security standard | Relevant wherever card payments are processed |
Two to start with: ISO 27001 for structure, and the data protection law of the country you want to work in. Our beginner guides explain ISO 27001’s clauses, Annex A and the ISMS and what SOC 2 is (and is not).
What skills does a GRC analyst need?
Core GRC skills
- Risk assessment: identifying assets, threats and vulnerabilities, and scoring risk consistently.
- Control knowledge: understanding what common controls are for (access control, logging, backups, change management, encryption, supplier management) and what good evidence looks like.
- Clear writing: policies, findings, risk descriptions and reports that busy people can act on.
- Attention to detail: an expired certificate date or a missing approval is exactly what auditors find.
- Stakeholder management: getting people who do not report to you to do things on time.
- Spreadsheets and tools: Excel or Google Sheets competently, and familiarity with GRC platforms helps.
How technical does a GRC analyst need to be?
More than many guides suggest. You do not need to exploit systems, but you must understand what you are assessing. If an engineer says “the database is encrypted at rest and only reachable from the app subnet”, you should know what that means, what evidence would prove it, and what it does not protect against. A good baseline is the content of CompTIA Security+: networking basics, identity and access management, cryptography concepts, cloud models and incident response. An analyst who can talk credibly to engineers gets better evidence, and gets it faster.
Sample GRC work you can practise this week
The best way to learn GRC, and to prove you can do it, is to produce the documents. Use a fictional company so nothing is confidential.
1. Build a small risk register
Use a simple scale: likelihood 1–5 and impact 1–5, multiplied to give a score out of 25. Agree what each number means before you score anything; consistency matters more than the scale you choose.
| ID | Risk | Likelihood | Impact | Score | Owner | Treatment |
|---|---|---|---|---|---|---|
| R-01 | Staff accounts compromised through phishing, leading to fraudulent payments | 4 | 5 | 20 | Head of IT | Reduce: phishing-resistant MFA for finance staff; payment approval by two people |
| R-02 | Customer data exposed through a misconfigured cloud storage bucket | 3 | 5 | 15 | Engineering lead | Reduce: configuration scanning; block public access by default |
| R-03 | Key supplier (KYC provider) suffers an outage | 2 | 4 | 8 | Operations manager | Reduce/accept: contractual uptime terms; documented manual fallback |
| R-04 | Laptop lost with unencrypted data | 3 | 3 | 9 | IT support | Reduce: enforce full-disk encryption; remote wipe |
Write a sentence under the table explaining the treatment options you used (reduce, accept, transfer, avoid) and why. That sentence is what interviewers ask about.
2. Test one control
Pick a control such as "Leavers' access is removed within one working day." Write a short test:
- Test: Compare the HR leavers list for the quarter against the access lists of three key systems.
- Sample: All leavers in the period (or a sample of 25 if there are many).
- Result: e.g. “2 of 11 leavers still had active accounts on the reporting tool, 9 and 23 days after leaving.”
- Finding and recommendation: Control not operating effectively; link the HR leaver process to automatic deprovisioning; add a monthly reconciliation.
That is the core loop of a lot of GRC work: control, test, evidence, finding, recommendation.
3. Draft one policy
Write a two-page access control policy for your fictional company: purpose, scope, roles, principles (least privilege, MFA, joiners-movers-leavers, periodic review), exceptions and review date. Keep it short; a policy nobody reads is not a control.
Put all three in a portfolio. They are far more persuasive than a list of frameworks on a CV.
How do you become a GRC analyst with no experience?
If you are coming from audit, legal, banking or admin
You already have a head start. Auditors know testing and evidence. Lawyers know regulation and careful drafting. Bankers know operational risk, controls and regulators. Administrators know process and follow-through. What you usually need to add is security knowledge and the vocabulary of the frameworks. We cover each route in moving into GRC from audit, legal, banking or admin.
If you are starting from scratch
Follow the foundations in our roadmap for getting into cybersecurity with no experience, then specialise:
- Learn security fundamentals (Security+ level).
- Learn one framework deeply (ISO 27001 is a strong choice) and your local data protection law.
- Build the three portfolio pieces above.
- Apply for roles such as GRC analyst, information security analyst (compliance), IT risk analyst, IT audit associate, compliance analyst, or third-party risk analyst.
Larger organisations, banks, fintechs, consultancies and audit firms all hire for these roles. Smaller companies selling to enterprise customers often need someone to handle security questionnaires and audits, which can be a good first role.
Which certifications help for GRC?
- CompTIA Security+: a broad technical baseline that many employers list.
- ISO/IEC 27001 Lead Implementer or Lead Auditor courses and exams, offered by various accredited training bodies; useful once you know which side of the audit you want to be on.
- ISACA’s CISA and CRISC, and ISC2’s CGRC: respected, but they require several years of relevant experience for full certification, so they are usually second- or third-step goals. Check ISACA’s and ISC2’s sites for current requirements.
Remember that a course certificate is not the same as an exam-based certification, and employers know the difference.
GRC analyst or SOC analyst?
Both are common entry points into security, and they suit different temperaments. SOC work is fast, technical and shift-based, reacting to alerts. GRC work is planned, document-heavy and business-facing, working in cycles of audits and reviews. If you are torn, read GRC analyst vs SOC analyst, and compare this guide with our SOC analyst roadmap.