Founder, Owner & Lead Engineer — RootCaws LLC
Boston, MA · USAF Veteran · President & Founder, GRC Engineering Club — Boston Chapter
Over a decade across enterprise SaaS, biotechnology, healthcare, and public-company security work — now building FAIR-based risk quantification, compliance-as-code, and AI-assisted GRC systems that replace the audit spreadsheet with something a board can actually read.
I architect and engineer the platforms myself: React/Vite front ends, Node.js/Express services, PostgreSQL data models, and evidence pipelines that pull continuous control evidence out of cloud infrastructure, IdPs, EDRs, and ticketing systems instead of asking a human to screenshot it.
The three case studies on the portfolio — same copy, same builds.
| What it means | Where it shows up | |
|---|---|---|
| 01 · Quantify | Turn cyber risk from a heat-map color into a defensible loss-exposure range. Eight browser tools run a real 10,000-trial Monte Carlo against sourced benchmarks, then plot the tail as a loss exceedance curve. | FAIR · Monte Carlo · Sourced benchmarks · Loss exceedance |
| 02 · Engineer | A control is held only when the evidence earns it — an executed attack that failed, a population that reconciled, or a withheld assertion rather than 0 of 0. Three public pipelines: AI, CUI, and FedRAMP 20x. | proofplane · OSCAL · FedRAMP 20x · Population reconciliation |
| 03 · Translate | Move technical exposure into a materiality decision leaders can defend. Item 1.05 quantitative screen, SAB 99 total mix, the four-business-day clock, and a contemporaneous memo — plus the OWASP severity rubric that stays a separate question. | SEC 8-K · SAB 99 · Item 1.05 · Incident severity |
Controls are the foundation. Everything else pulls from the controls. Build controls out properly and audit evidence, risk, policy, and compliance automatically compose. Miss the layer a control sits at — product, platform, customer, enterprise — or what it costs to own, and you'll never calculate risk, mature controls, set realistic KRIs/KPIs, or run continuous monitoring. Bad control data is the path to a failing GRC program.
Financial quantification in GRC is non-negotiable. Heatmaps are dead. Red is a color, not a unit of risk measurement. You cannot tell leadership "how risky" something is by calling it red. FAIR gives you defensible loss exposure ranges a CFO can budget against.
Risk is not a point in time. Risk is scenarios. Static risk registers are legacy. We run scenarios, Monte Carlo simulations, and loss exceedance curves to show where threats actually live. When risk is forward-looking instead of reactionary, you have a mature program.
GRC engineering and automation take programs to the next level. Manual workload eventually takes its toll and fatigue causes error. Automate the workflows and engineer the solutions — AI for risk scoring, questionnaire response, vendor assessment, and threat modeling. AI and engineering take already-mature programs to the next level, and give struggling teams a shortcut to the top.
Grouped the same way as the portfolio case studies. Each risk-lab tool also has a shareable tab on the site (#/risk-tools/<tab>).
01 · Quantify — case study
| Project | What it does |
|---|---|
risk-quantifier HTML |
Place risks on a 5×5 heat map, give each a frequency and loss range, then run 10,000 Monte Carlo iterations and watch the matrix become a distribution. Source-backed benchmarks instead of invented ranges; mixed-currency portfolios are refused rather than silently summed. Lab · Live |
risk-benchmarks JSON · Python · HTML |
The numbers behind the lab. Twelve shards, 72 parameters, every one citing a public study with its date, confidence, and the limitation on its use. Lab · Live |
loss-exceedance-curve HTML |
Overlay risk tolerance, loss reserves, and materiality on a curve — the odds of crossing each one. Lab · Live |
fair-model-study HTML |
Rebuild the FAIR tree from memory. Load a benchmark and exactly two of thirteen nodes fill in, because that is all a published loss study measures. Lab · Live |
monte-carlo-demo HTML |
Why the average settles long before the one-in-a-hundred year does. Lab · Live |
ai-risk-register HTML |
Twelve seeded AI scenarios through a 10,000-iteration Monte Carlo, with coverage against NIST AI RMF 1.0 and ISO/IEC 42001 Annex A. Lab · Live |
risk-benchmarks-integration Write-up |
How those sourced numbers were wired across the lab, the nine defects the integration found, and why a published loss study fills two FAIR nodes out of thirteen. |
02 · Engineer — case study
| Project | What it does |
|---|---|
proofplane TypeScript · Python · Go |
An AI governance control plane where a control is satisfied only when an executed adversarial attack failed. Twelve controls, a 144-run independence matrix, hash-chained evidence with Wilson intervals, NIST-valid OSCAL, and a CycloneDX ML-BOM with file-and-line provenance. Live |
ksi-harness TypeScript · Rego |
Continuous control monitoring for FedRAMP 20x. Pins FedRAMP's machine-readable rules, reconciles populations, gates IaC before merge. An indicator only reaches automated when someone writes an argument that its checks leave nothing material out — which is why the headline number is currently zero. Companion logs: ksi-anchors. |
cui-control-plane TypeScript |
One control inventory for a DoD CUI boundary. Five NDAA-driven regimes as crosswalk edges. Emits OSCAL O1–O5 with deterministic v5 UUIDs, derives SPRS from assertion records, and withholds a control rather than reporting 0 of 0. |
u-dont-grc-me TypeScript |
Control-centric GRC product prototype — the same thesis as a working UI. Command center, audit package assembly, 10,000-trial FAIR engine. React/Vite over SQLite locally and a read-only Lambda/DynamoDB API when hosted. Live |
proofscan TypeScript |
Layered scanner that proves the bug it finds. A finding is verified-exploitable only once a generated attack changed another user's data, and fixed-verified only when that attack no longer reproduces. Command-line; nothing deployed. |
03 · Translate — case study
| Project | What it does |
|---|---|
cyber-materiality-workbench HTML |
Work an incident through an SEC Item 1.05 determination — quantitative screen, SAB 99 total mix, four-business-day clock, contemporaneous memo. Either leg can carry the call. Lab · Live |
incident-severity-calculator HTML |
Sixteen OWASP Risk Rating factors, likelihood and impact kept separate. The argument becomes "you scored detection at 9 and I scored it at 3." Lab · Live |
portfolio is the site itself: xnasusx.github.io/portfolio.
Risk & Quantification
Frameworks & Standards
Build
Cloud & AI
GRC Platforms
GRC Engineering Credentials
| Credential | Issuer |
|---|---|
| Certified Information Security Manager (CISM) | ISACA |
| Certified in Risk and Information Systems Control (CRISC) | ISACA |
| Advanced in AI Security Management (AAISM) | ISACA |
| Advanced in AI Risk (AAIR) | ISACA |
| Certified in Cybersecurity (CC) | ISC2 |
| AWS Certified Cloud Practitioner (CLF-C02) | AWS |
| Certified GRC Engineer — Practitioner (CGE-P) | GRC Engineering Club |
| Certified GRC Engineer — Auditor Specialty (CGE-AUD) | GRC Engineering Club |
- M.S. Computer Information Systems, Concentration: Security — Boston University
- B.S. Information Technology, magna cum laude — UMass Lowell
 |
You Don’t Build a Garden Around the Blight Jul 31, 2026 Why Controls Should Be the Soil a GRC Program Grows From — Not the Harvest It Inspects Most GRC programs are built backward. They start with... |
 |
Hari Seldon Would’ve Made a Great CISO Jul 13, 2026 What Cyber Risk Analysts Can Learn From Asimov’s Foundation In Isaac Asimov’s Foundation series, mathematician Hari Seldon develops “psychoh... |
- President & Founder — GRC Engineering Club, Boston Chapter. Building the local practice around systems, automation, and modern controls work.
- ISACA AAISM beta tester and Exam Writing Development Group writer.
- ISC2 technical guidance paper co-author and subject matter expert.
- Writing at medium.com/@xnasusx.
- Mentoring through ISACA, Big Brothers Big Sisters, and Boston University Admissions.
