Tracks
Five role tracks share a placement-gated Common Core, then specialize by the object they engineer, then reconverge at a shared capstone showcase. Pick yours — it shows on your dashboard.
GRC Engineer — Generalist *(default track)*
The object it engineers: the whole control loop, end-to-end, across all four specialist domains — the connective tissue.
Jobs-to-be-Done
- Convert manual GRC toil into engineered systems so assurance is continuous, not point-in-time.
- Be the integration layer: make control/risk/evidence data flow across cloud, IdP, HRIS, ticketing, CI/CD.
- Translate between engineers, auditors, and leadership.
Role Spine (deep)
Common Core at full depth, then working depth across all four specialist spines plus a spike in integration / data-pipeline engineering (schema mapping, ETL, normalization, dashboards, SQL + BI). Deep on: 01–07, 13, 14; working on 08–12.
Role Capstone
Ship one real control end-to-end across all loop stages — designed-left, policy-as-code enforced, evidence auto-collected, continuously monitored, OSCAL-expressed, owned as a product. The synthesis capstone; the others are specializations of it.
Sub-scale orgs collapse the five roles into 1–2 people — this track is how that compression is taught explicitly, not by accident.
Governance Engineer
The object it engineers: the policy & control architecture — the organization’s single, versioned, machine-readable source of truth for controls.
Jobs-to-be-Done
- Make the control framework code: adding/changing a framework is a reviewed diff, not a project.
- Keep policy, standards, and cross-framework crosswalks authoritative and current.
- Automate governance / exec / board reporting from the catalog.
Role Spine (deep)
Policy-as-Code (Cedar → OPA/Rego → Kyverno) · the standards spine (NIST 800-53 superset + crosswalks) · OSCAL authoring + Trestle · control-catalog versioning · governance/exec reporting automation. Deep on: 08, 09, 10, 12; working on the Common Core, 13.
Role Capstone
Convert our control catalog into a versioned, crosswalked OSCAL source of truth with one control’s policy enforced as code and exec-reporting auto-generated from it.
Corpus note: Governance was the thinnest slice of the LinkedIn corpus (~6) — this definition rests on the GitLab Security-Governance job-family handbook + named 2025–2026 postings, not the corpus. Validate against real Vanta governance work as the track runs.
Risk Engineer (first-party + third-party)
The object it engineers: the risk models and the risk/vendor data pipeline — risk made quantified, current, and decision-grade.
Jobs-to-be-Done
- Replace qualitative heatmaps with quantified, continuously-updated, $-denominated risk.
- Make third-party / vendor risk a continuous monitoring pipeline, not an annual questionnaire.
- Produce decision-support for remediation arbitration (not audit evidence).
Role Spine (deep)
Quantitative risk (FAIR, Monte Carlo, How to Measure Anything in Cyber Risk) · risk-register- as-code · control-effectiveness telemetry · third-party/vendor risk (vendor inventory automation, continuous vendor monitoring, automated questionnaire intake/scoring, SBOM/supply-chain, concentration risk). Deep on: 05, 06, 07, 11, 14; working on the Common Core, 13.
Role Capstone
Build a continuously-updated quantified risk model for one first-party risk and one automated continuous-monitoring pipeline for a third-party vendor, both emitting a loss-exposure metric.
Explicitly distinct from Compliance — do not make risk a compliance control. Risk produces decision-support; Compliance produces audit evidence. (Corpus-validated: Risk was well-represented.)
Compliance Engineer
The object it engineers: evidence & audit-readiness — proof that controls operate, produced automatically and continuously.
Jobs-to-be-Done
- Make the org continuously audit-ready with zero manual evidence collection.
- Detect control gaps before auditors do; turn audits into exports, not fire drills.
Role Spine (deep)
Evidence-as-code pipelines · continuous controls monitoring (control → check → evidence → drift alert) · API evidence collection at scale · framework-mapping execution · automated gap detection · audit-prep automation · IaC scanning in CI. Deep on: 01–07, 08, 10, 12, 13; working on 09.
Role Capstone
Stand up a continuous-controls-monitoring loop for one framework area: automated checks → versioned evidence store → drift alert → auditor-ready export, with zero manual evidence toil.
Deep certification-framework fluency (SOC 2, ISO 2700x, FedRAMP, PCI-DSS, HIPAA, C5) is the governance backdrop; the engineering spike is evidence-as-code + CCM, not the certificates.
Customer Trust & Assurance Engineer
The object it engineers: the customer-facing trust surface — the security program externalized for revenue. (The manifesto’s “stakeholder-as-customer” value, made literal.)
Jobs-to-be-Done
- Make security posture self-serve and instantly verifiable for prospects/auditors.
- Take security questionnaires/audits off the deal critical-path; position the company as a security leader.
Role Spine (deep)
Trust Center automation · security-questionnaire/RFP automation (answer engine over a maintained response DB / RAG) · customer-audit support tooling · gated attestation/report distribution + access control · contractual/SLA evidence · public posture · outward technical communication. Deep on: 05, 06, 13, 14; working on the Common Core, 12.
Role Capstone
Automate the customer trust loop: a self-serve Trust Center fed by the same evidence pipeline Compliance builds, with gated report distribution and a questionnaire-answer engine — measured by reduction in manual questionnaire turnaround.
Corpus note: Customer Trust & Assurance had ~0 corpus depth (LinkedIn’s job-view SPA stopped exposing JD bodies mid-harvest). This definition rests entirely on the GitLab Field-Security / Customer-Assurance specialty + Ayoub Fandi’s “Security Assurance Automation” title family + named postings — treat as a deliberate design to validate against real Vanta trust-surface work.
Coverage matrix
Depth per module per track. D = Deep / author-level · W = Working / can operate · A = Awareness / can converse. Tracks diverge after the Common Core and reconverge at the shared Role Capstone showcase.
| Module | Generalist | Governance | Risk (1st+3rd) | Compliance | Cust. Trust & Assurance |
|---|---|---|---|---|---|
| Part I — What GRC Engineering is + the loop | D | D | D | D | D |
| 01 — Terminal & CLI | D | W | W | D | W |
| 02 — Linux system fundamentals | D | W | W | D | W |
| 03 — macOS fundamentals (fleet-split) | D | W | W | D | W |
| 04 — Windows fundamentals (fleet-split) | D | W | W | D | W |
| 05 — Programming + Git (centerpiece) | D | W | D | D | D |
| 06 — APIs (Tier-1 capstone) | D | W | D | D | D |
| 07 — Data & cloud control plane (SQL + IAM + audit logs) | D | W | D | D | W |
| 08 — IaC + scanning in CI | W | D | W | D | A |
| 09 — Policy as Code | W | D | W | W | A |
| 10 — The standards spine + crosswalks | W | D | W | D | W |
| 11 — Threat-informed GRC + systems/design thinking | W | W | D | W | W |
| 12 — OSCAL & compliance-as-code | W | D | A | D | W |
| 13 — Continuous Controls Monitoring | D | W | W | D | D |
| 14 — Product, ownership, build-vs-buy + risk quantification | D | A | D | W | D |
| 15 — Capstone: ship one control, fully engineered | D | D | D | D | D |
| IT-foundations band (16–25) — the substrate every control claim rides on | |||||
| 16 — IT networking fundamentals (on the wire) | W | W | W | W | D |
| 17 — Databases relational & NoSQL (truth at rest) | W | W | W | D | W |
| 18 — Web application architecture (the tiers) | W | W | W | W | D |
| 19 — IT API paradigms (REST/SOAP/GraphQL/gRPC) | W | W | W | W | D |
| 20 — Cloud shared responsibility (the boundary) | W | D | W | D | D |
| 21 — Containers & virtualization (peel the image) | W | W | W | W | D |
| 22 — Applied cryptography & PKI (read the cert) | W | W | W | W | D |
| 23 — Identity, AuthN/AuthZ protocols (the valet key) | W | W | W | W | D |
| 24 — How the internet works (the request lifecycle) | W | W | W | W | D |
| 25 — Logging, telemetry & observability (the proof) | D | W | W | D | D |
IT-foundations band (16–25): the technical substrate the GRC canon sits on — where a control claim’s truth physically lives, travels, and how to read it. Shared by all tracks at Working depth; the Customer Trust & Assurance track goes Deep on the wire/web/API/crypto/identity modules (the auditor-facing evidence surface). Placement-gated like Tier 1: demonstrated competence skips the module. Every module is framed by its loop question, never “learn this stack.”
Fleet split (03 vs 04): each learner goes Deep on the org’s dominant endpoint platform and takes the other at Awareness only. Nobody does both deeply unless their role demands it.
Placement: each module’s competence artifact is its placement test — demonstrated competence skips the module regardless of track.