What the work actually looks like.
Three client engagements described in full — including one that didn't go the way it should have — then a field note on a decade of federal accreditation work. Client names are withheld where the agreement requires it. Everything else is exactly as it happened.
Inheriting a struggling ISMS and taking it through the 2022 transition
The situation
The organization held an ISO 27001:2013 certification that had drifted. Documentation didn't match practice, stale processes, old services listed, and a surveillance audit was approaching. On top of that, the 2022 revision meant the entire ISMS had to be transitioned before the deadline — a project nobody internally had the bandwidth or the framework expertise to own.
What I did
First, stabilize. I ran a full internal review ahead of the surveillance audit, rebuilt and constructed new documentation to reflect what was actually happening, and updated processes to close prior failures. Surveillance closed with two minor nonconformities.
Then the transition. I owned it end to end: a complete gap analysis against the 2022 standard, the remap of Annex A from 114 controls to the current 93 across the four themes, authorship and ownership of the Statement of Applicability, and a rebuilt internal audit program. I led the four-person security and IT team through the audit cycles and served as the point of contact for the certification body.
All of it ran alongside an ISO 20000-1 service management system as an integrated program, which roughly doubles the coordination load: two sets of management reviews, two internal audit programs, and overlapping evidence that has to satisfy both standards without contradicting itself.
The part most transitions get wrong is treating the Annex A remap as a one-to-one exercise. It isn't — controls merge, split, and change intent. Getting that mapping right is the difference between a clean transition and a findings list.
The other thing worth saying plainly: this engagement took over a year, and the reason was executive sponsorship, not technical difficulty. That matches what the standard's own practitioners report — programs that stretch past twelve months are almost always suffering from an absent sponsor or undefined scope rather than anything inherent to ISO. It's why my current engagements start by naming who signs risk acceptances before anything else happens.
The outcome
Certified against ISO 27001:2022 with three observations and zero nonconformities.
Standing up an entire security and cloud function at a 14-person company
The situation
A cloud-native platform serving power systems, microgrids, and large-load manufacturing customers — running production workloads for industrial clients with no dedicated security or IT function. Fourteen people: a CEO, a CTO, eight developers, QA, HR, and media staff. Enterprise customers were beginning to ask for a SOC 2 report they didn't have, and nobody owned the answer.
Why they hired me
Not for compliance. They needed someone who could actually build — architect the cloud, fix identity, harden the pipeline — and the SOC 2 requirement was what made the hire urgent. A compliance consultant would have handed them a findings list they had nobody free to work.
The engineering
Cloud architecture. Designed and now administer two Azure environments, each with segregated development and production customer boundaries, standardizing IAM, network segmentation, and tenant isolation across the estate.
Identity. Consolidated seven business and engineering applications onto Entra ID SSO using OIDC and SAML across both gallery and custom enterprise app registrations, with MFA and conditional access enforced as the single authentication path.
Source control and pipeline. Administer GitHub Enterprise Managed Users across the engineering org: organization and team structure, repository and self-hosted runner hardening, branch protection, and secret and code scanning enforcement.
Process automation. Rebuilt onboarding, offboarding, and periodic access reviews as a repeatable automated process that produces its own audit evidence — the part most companies reconstruct by hand every cycle.
Then the compliance program
With the environment actually built, SOC 2 became tractable. I ran an independent platform evaluation, selected Vanta, and integrated it so evidence collection runs continuously rather than getting reconstructed by hand each cycle. Control design, policy authorship, and the auditor relationship followed — on top of infrastructure that could genuinely satisfy the controls instead of paperwork claiming it did.
That ordering is the whole point. Most SOC 2 engagements at this size produce a policy set and a findings list against an environment that cannot support either. Here the identity architecture, the segmentation, and the access review automation existed first, so the controls described something real.
What got built
A company that started with no security function, no identity strategy, and no evidence pipeline finished with all three in four months, plus a documented SOC 2 program running on top of them. The engineering is the durable part — it outlasts any particular audit cycle, and it is what I was hired to do.
A hospital system, a prime who overbid, and the engagement that changed how I scope
The situation
I came in as a subcontractor to a prime who had bid patching work they weren't able to deliver. The hospital needed to pass a vulnerability management assessment. Two IT people covered both helpdesk and security for the entire organization. There was no asset inventory, no standardized credentials across network devices, and no reliable record of what hardware existed or where it physically sat.
What that environment does to scanning
Scanning ran uncredentialed via a third party — most likely because there was no consistent way to authenticate to the devices, or because nobody explained the requirement to the hospital customer. Uncredentialed scans infer findings from banners and service responses instead of checking the system, so the output was thousands of findings nobody could validate — not me, not the prime, not the client.
The findings we could confirm were the ones observable without credentials: network devices running SNMPv1 with default community strings. Unambiguous, serious, and fixable. Those got fixed.
I was hired to fix findings, but really, it was scoped around the assessment. The client wanted the report items closed rather than the underlying conditions addressed. A meaningful share of the work went into making findings stop appearing rather than making systems stop being vulnerable. Where their IT team chose to suppress findings instead of fixing them, I recommended against it — but it was their network to manage, not mine, and we were directed toward other issues. The assessment passed. The hospital was not materially safer, and I've never been comfortable with that.
What I'd do differently, and what I'd defend
Part of what happened was a legitimate answer expressed badly. In healthcare a real share of unpatchable findings are genuinely unpatchable — FDA-cleared medical devices often can't be patched without affecting their clearance, and the correct response is documented compensating controls plus network segmentation, not remediation. That position holds up under scrutiny. Nobody on that engagement, including me, framed it that way at the time.
The rest of it doesn't hold up. It happened because the engagement was scoped to satisfy an assessment rather than fix an environment, and because the prerequisites that make scanning meaningful were never treated as part of the work.
What changed as a result
Every vulnerability management engagement now opens with a foundation phase — asset inventory, standardized credentialed access, device authentication brought to a standard — because scanning without those produces numbers rather than information. Findings get validated before they reach the client, with the reasoning written down. Anything genuinely unpatchable gets documented compensating controls and segmentation rather than a suppression rule.
And if the real goal is passing a scan rather than fixing an environment, I say so on the first call. This engagement is where that policy comes from. I'd rather lose the work than repeat it.
A decade of federal accreditation, summarized honestly
This one isn't a client engagement — it's a pattern from years of federal work carried out under prior employers. No client or system is identified and nothing specific is disclosed. It's here because it explains why my engagements are scoped the way they are.
What a decade under DoD RMF teaches you — including what it gets wrong
The background
Two years auditing programs for the Department of Defense Office of the Inspector General, then years on the build side running continuous monitoring across 20+ geographically separated networks and 5,000+ endpoints, leading ATO packages, and preparing organizations for Command Cyber Readiness Inspections. Both sides of the table, under the strictest control regime in general use.
What RMF gets right
The process makes sense and the controls are understandable. Nothing is complete or met until there is evidence, and then it is done. Continuous monitoring is the key to a good authorization standing. Every finding carries an owner and a milestone date — that is what a POA&M is, and it exists because “we'll get to it” was found insufficient a long time ago. Configuration baselines are specific and testable rather than aspirational; a STIG tells you the setting, not the sentiment. And assessors show up in person and check, which changes behavior in ways a questionnaire never will.
Those habits transfer directly to commercial work, and they're why a 90-day SOC 2 timeline is realistic rather than optimistic. Capture evidence when the work happens instead of reconstructing it later, and most of the audit panic disappears.
What it gets wrong
Inheritance is rarely built. GRC tool managers at the organizational level do not build the inheritance models that the systems and networks underneath them will need, so every system re-documents what the enclave already provides.
Separation of duties barely survives contact with staffing. It is just as hard in the commercial world: ISSMs acting as security control assessors, ISSOs doing the engineering work they are supposed to be assessing, a single ISSO carrying multiple systems, or continuous monitoring consuming the entire role. Think of ISSOs as internal auditors — that is why keeping them in one lane is so difficult.
Documentation displaces security. RMF is heavy enough that satisfying it becomes a full-time job, and when the paperwork is the deliverable, teams optimize for the paperwork. I have seen beautifully written System Security Plans describing controls that were not operating, standards and templates checking boxes with no actual implementation behind them, poor evidence submissions, and POA&Ms tracked meticulously — or not at all — for years without anything being remediated.
Exclusion rules are hard to come by. A cloud-hosted system should have the physical controls excluded outright, and getting agreement on that is harder than it should be.
The volume is defeating. Control sets large enough that nobody reads them get delegated to whoever has capacity rather than whoever understands the system. Accreditation timelines long enough that the environment materially changes mid-assessment mean you certify a system that no longer exists. A regime that treats every control as mandatory regardless of context trains people to stop thinking about risk and start thinking about coverage. And systems stay behind on the move from Rev 4 to Rev 5, the same way they stayed behind moving from DIACAP to RMF.
Reciprocity mostly does not work. Every organization runs RMF its own way and on its own GRC tool — I have seen this first hand across varying DoW and federal organizations. The concept was sound: if org 1 and org 2 run the same system, org 2 rides on org 1's package, allowing for hardware, software and PPSM differences. But the network underneath that system is fundamentally different every time, and defense in depth makes those differences decisive. Reciprocity ends up nearly impossible in practice.
And not enough automation. This is the gap OSCAL may close, and the reason I pay attention to it.
The honest summary: RMF is a rigorous framework frequently applied in a way that produces documentation rather than security. It is far heavier than SOC 2 or ISO 27001, and heavier does not automatically mean better.
Why it matters for commercial work
Two things come out of it. The discipline — evidence, owners, milestone dates, testable baselines — is worth importing wholesale, and most small companies have none of it.
The caution is worth importing too. Having watched compliance programs consume the security function they were meant to serve, I scope engagements to build things rather than describe them. A control is a thing you deploy, not a paragraph you write. That view is the direct result of a decade spent watching the alternative.