Cyber, Risk & Internal Audit
Security GRC & Risk
GRC used to mean spreadsheets and questionnaires. The postings now ask for code — and increasingly for someone who can govern AI without blocking it.
Governance, risk and compliance appears in 78% of security postings, which makes it the most pervasive activity in the family. What has changed is how it is done: the corpus is full of titles like GRC Engineer and Fullstack Software Engineer, GRC, because compliance evidence at scale is a data problem and the manual version does not survive growth.
A day
| Time | What you are actually doing |
|---|---|
| 09:00 | A customer security questionnaire, 180 questions. You answer forty from the knowledge base automatically and spend real time on six that are genuinely new. |
| 10:30 | Evidence collection for SOC 2. Not screenshots — you are writing a script that pulls control evidence from the cloud API on a schedule, because screenshots are stale the moment they are taken. |
| 13:00 | Risk register review with an engineering lead. Two risks get closed because the control changed, one gets re-rated because the business changed. |
| 14:30 | A vendor review. The vendor is a model provider, so the questions are about training on customer data, retention, sub-processors and how you find out when the model changes underneath you. |
| 16:00 | Draft an AI acceptable-use policy that engineering will actually follow, which means it is one page and names the sanctioned tools. |
The decisive round
“Walk me through how you'd get us SOC 2 ready.”
Interviewer: “We have no compliance programme and a customer is asking for SOC 2 Type II. Where do you start?”
A weak answer. “I'd start with a gap assessment against the Trust Services Criteria, define the control set, write the policies, then work with teams to implement and gather evidence ahead of the audit window.” Correct, generic, and describes a year. It also does not mention the customer who triggered this, which is the actual driver.
A strong answer. “First I'd find out what the customer actually needs and by when, because that determines whether we're doing Type I in eight weeks or Type II with a three-month observation window, and those are different projects. Teams routinely commit to Type II without realising the clock only starts once controls are operating.
Then scope hard. SOC 2 scope is our choice, and the most common mistake is including every system because it feels more rigorous. I'd scope to the product and the infrastructure it runs on, and exclude the corporate estate unless the customer specifically requires it.
Then I'd invert the usual order: instead of writing policies and hoping controls follow, I'd look at what we already do, document that as the control, and only change practice where there's a genuine gap. Most engineering teams already do access review and change management informally — the gap is evidence, not behaviour.
And I'd automate evidence from day one. Screenshots in a folder is the failure mode that makes year two worse than year one. Pull control evidence from the cloud APIs on a schedule so the audit is a query rather than a scramble.
Realistically: Type I in about ten weeks, Type II three months after that.”
The strong answer knows where the project actually fails — scope creep and evidence debt — and gives a date. Interviewers for this role have been through a bad audit and are listening for someone who has too.
What to build
- Automated evidence collection. A script that pulls a real control's evidence from a cloud API on a schedule — MFA coverage, encryption at rest, access review status. This is what separates a GRC engineer from a GRC analyst, and the pay difference is large.
- A risk register you would defend for a system you know, with ranges rather than point estimates and a stated basis for each.
- An AI acceptable-use policy that fits on one page and names sanctioned tools, a data classification ceiling, and an exception path. Very few candidates bring one and it is immediately relevant.
- A control mapping between two frameworks — SOC 2 and ISO 27001, say — so you can talk about doing the work once and reporting it twice.
A vulnerability in a widely used file-transfer product exposed data at hundreds of organisations who had never heard of the vendor's vendor. Third-party risk arriving through a fourth party.
Use it to say: “It changed how I scope vendor review. I ask what our vendors' critical dependencies are, because that's where the exposure actually was.”
Attackers accessed a support case management system containing session tokens uploaded by customers for troubleshooting. Downstream customers were then targeted.
Use it to say: “My takeaway is about what we send vendors during support. HAR files and debug bundles routinely contain live credentials, and almost nobody scopes that in vendor review.”
A remote access portal without multi-factor authentication led to a breach that disrupted healthcare payments across the United States for weeks.
Use it to say: “This is my argument for coverage metrics over policy existence. They had an MFA policy. What they didn't have was a number for what percentage of access paths enforced it.”
A three-week plan
Week 1 — the artefact
Days 1–3: Write the evidence-collection script against a free-tier cloud account. Make it output something an auditor would accept.
Days 4–5: Build a control mapping between SOC 2 and ISO 27001 for ten controls you understand.
Week 2 — the judgement
Days 1–2: Write a risk register for a real system, with ranges and stated assumptions.
Days 3–5: Draft the one-page AI acceptable-use policy, and a two-page vendor-review standard for model providers.
Week 3 — rehearse
Days 1–2: Practise the SOC 2 answer aloud with dates in it.
Days 3–4: Practise the harder one: a finding management disagrees with, and how you record acceptance.
Day 5: Five stories — an audit you ran, a control you automated, a risk you were wrong about, a disagreement you recorded, a 'no' you turned into a 'yes, if'.
Red flags
GRC with no engineering access. If you cannot get read access to the systems you attest about, you are writing fiction and will be blamed for it later.
Certification as the goal. A team that wants the badge rather than the controls will pressure you to attest to things that are not operating. That is a career risk, not just an ethical one.
No named risk owner. If risks live in your register and nobody else's objectives, nothing will ever be remediated.
Compensation
| Market | Band | Notes |
|---|---|---|
| United States | $130k – $220k base | GRC engineers with real automation sit $40–60k above analysts |
| India | ₹18L – ₹45L total | Large GCC market — banking, insurance, healthcare, SaaS |
| Both | — | The automation skill is the whole differentiator. Spreadsheet GRC is being compressed |
The book for this field
Securing & Governing AI
The attack surface that is genuinely new, the risks that are old in new clothes, model risk, what audit evidence looks like, the frameworks, responsible AI as controls rather than principles, the enterprise AI gateway, measuring harm, and what the law actually requires.
Also read for this role
Microsoft 365 & Copilot in the Enterprise
How a Microsoft 365 estate is actually built, licensed and governed — tenant, identity, workloads, devices, Purview and Defender, every licence tier with current prices, and then Copilot and Copilot Studio from the request path to the evidence on whether they deliver.
All 12 chapters in Microsoft 365 & Copilot in the Enterprise →
Cross-cutting
Skills every archetype tests
These are shared across every field on this site — the same question asked in different vocabulary — so preparation here compounds rather than being spent once. The book above is specific to your field.
Practice the 12 Security questions → · Back to Cyber, Risk & Internal Audit →