A day in the life

Most job listings describe a GRC Engineer in abstractions: "implement controls," "support audits," "automate compliance." Read three of those and you still can't picture the work. Here's what the day actually looks like at three different sizes of company.

At a Series A startup (20 people)

You're the first compliance hire. The CEO promised an enterprise customer that SOC 2 Type 2 will land in six months. You don't have a security team to back you up — you have engineers who are friendly but busy.

Monday morning you open the SOC 2 Trust Services Criteria and find CC6.1: "The entity implements logical access security software, infrastructure, and architectures over protected information assets." You ask the senior engineer what authentication looks like today. The answer is "Google OAuth, mostly." You spend the afternoon writing it down: who can sign in, what they get access to, whether MFA is enforced (it isn't for the founders, who keep meaning to set it up).

By Wednesday you've written a five-line proposal: enforce MFA on Google Workspace, route all admin access through Okta, kill the three personal access tokens still in CI. The engineer reviews it, agrees, and ships it in two PRs.

Friday you write the control narrative the auditor will see in six months. It cites Okta as the IdP, lists the conditional access policy, and points to the Terraform module that enforces it. Three weeks of work, one auditor satisfied.

At a scale-up (300 people)

You're employee number two on the GRC team. The company has SOC 2 already and is adding ISO 27001 + HITRUST. Your manager owns the policy side; you own the technical side.

Monday is the weekly access review. You query Okta for everyone with production AWS access and compare it against the engineering org chart. Three contractors offboarded last month still have console roles. You file Jira tickets, attach the evidence, and Slack the engineering manager.

Tuesday afternoon you pair with an SRE on a Terraform module. The new ISO control requires that production EBS volumes are encrypted with customer-managed keys. The old default-provider-key behavior would pass SOC 2 but not ISO. You write a Terraform Sentinel policy that blocks aws_ebs_volume resources without kms_key_id. The SRE adds it to the CI gate.

Thursday is audit prep. You're not actually in the audit — that's three months out — but the auditor has asked for a sample of evidence. You pull 30 days of CloudTrail logs filtered to ConsoleLogin events, sample 20, and write a one-page narrative explaining how each one satisfies CC6.1.

Friday you spend on automation. You're building a Steampipe dashboard that flags any IAM policy with wildcard actions on production resources. Right now it would surface 14 findings. By end of quarter you want it to be zero.

At an enterprise (5000 people)

You're a senior IC on a GRC engineering team of twelve. The company is publicly traded; the audit cycle is continuous.

Monday morning you're on a call with three people: an engineering director, a vendor security analyst, and someone from legal. The director's team is integrating a new third-party data processor. You walk through the questionnaire response, flag two answers that don't match the vendor's actual SOC 2 report, and decide together whether to push back on the vendor or accept the gap and document a mitigation.

Tuesday you spend hours in code review. The platform team is migrating from manual access provisioning to a SailPoint workflow. You're not writing the code — you're verifying that every CC6.2 evidence requirement is captured: who requested access, who approved, when it was granted, when it was reviewed. You leave 14 comments, most of them about whether the audit log entries will satisfy the auditor's "operating effectiveness" standard.

Wednesday is detection-as-code work. You're writing Sigma rules for unusual privileged actions in AWS. Your platform team ships the rules to the SIEM; the IR team owns triage. You don't get paged when one fires — but you do get summoned to write the post-incident report that the auditor will read.

Friday you write a memo. Internal Audit asked whether your continuous evidence pipeline can replace the quarterly manual sampling exercise. Your answer is "for these 18 controls, yes; for these 6, no." Two thousand words, three diagrams. By Monday it'll be in front of the CISO.

What the three jobs have in common

Different sizes, very different rhythms — but the same skill underneath. A GRC Engineer looks at a control written by a framework committee and immediately asks: how can a system enforce this, prove it, and tell me when it stops?

Compliance Analysts read frameworks and write documents. Cloud Engineers build infrastructure but rarely think about controls. A GRC Engineer is the person who bridges them — fluently, technically, and in code where possible.

That's the role. The next lesson covers why it didn't exist a decade ago and why it's accelerating now.