Why this exists

I'm Ashley Pearce, a GRC engineer. I've spent more than a decade in GRC, across the Air Force, federal programs and enterprise companies, most of it close to authorizations, continuous monitoring and the pipelines that are supposed to prove a control works.

Most of what I know, I learned in the middle of something: a vendor review due by five, an assessment window opening on Thursday, an ATO that was due before anyone was ready. None of those came with a practice run.

I'm still learning, and I'm not trying to define GRC for anyone. There are courses and frameworks for that. What I can share is the work itself: the situations I've been in, and the labs I built to close my own gaps.

So that's what this is. The Traditional GRC path is scenarios you work through in the browser, the kind of calls the job actually asks you to make. The GRC Engineering path is builds you do for real, in your own Codespace and cloud account, so you finish with code and evidence you can walk an interviewer through.

If it helps you in an interview or on a real review, tell me on LinkedIn.

This is my own project, built in my own time. It isn't connected to my employer, and the companies and people in the scenarios are made up.