Every Framework Reduces to the Same Question
Strip the vocabulary away from FedRAMP, SOC 2, CIS, ISO 27001, or HIPAA and you arrive at the same place: who can reach this system, what can they do once they are in, how did they get that access, and can you demonstrate all of it to someone who does not trust you.
That is an identity problem. The frameworks differ in structure and emphasis, but none of them has an answer that does not begin with identity. It is the shared root, which is why we treat it as the first piece of work rather than one workstream among many.
Why Identity Comes Before Everything Else
The dependency runs one way. Almost every other control family assumes a trustworthy identity layer already exists underneath it:
- Audit and accountability depends on knowing who the actor was. A complete audit log with unreliable identity attribution proves very little.
- Access control is unenforceable if provisioning is inconsistent. Policy that says least privilege means nothing if access is granted ad hoc and never reviewed.
- Configuration management needs a reliable answer to who changed this and whether they were authorized to.
- Incident response lives or dies on how fast you can determine blast radius, which is an access question.
- Personnel security is only real if offboarding actually revokes access rather than filing a ticket that revokes it eventually.
Build these on weak identity and you generate findings that all trace back to the same root cause. You end up remediating symptoms repeatedly while the underlying issue stays in place.
The Three Things We Fix First
Authentication
Establishing that a person is who they claim to be, at a strength appropriate to what they can reach. Phishing-resistant factors for privileged paths, consistent enforcement rather than per-application exceptions, and no long-lived shared credentials sitting outside the identity provider.
Provisioning
The joiner, mover, and leaver lifecycle. Most organizations handle joiners reasonably well because someone complains when access is missing. Movers and leavers are where entitlement accumulates silently—nobody files a ticket about access that should have been removed. This is the single most common source of findings we see, and it is fixable.
Access review
Demonstrating on an ongoing basis that current access is still appropriate. Done manually this is a spreadsheet exercise that managers rubber-stamp under time pressure. Done properly it is a continuous, evidence-producing process that surfaces genuine anomalies rather than asking for bulk approval of things nobody has time to evaluate.
What Automated Actually Means Here
Automating identity is not buying an identity provider and declaring the control satisfied. The work is making the identity layer continuously produce its own evidence:
- Entitlements pulled from source systems on a schedule, not reconstructed by hand before an audit
- Provisioning and deprovisioning events captured as artifacts at the moment they happen
- Access reviews that generate a defensible record of who reviewed what and what changed as a result
- Drift detection that flags privilege accumulation as it occurs rather than at the next review cycle
- Every artifact mapped to the control statements it satisfies, so the evidence is usable rather than merely collected
Do this and identity stops being a control family you prepare for. It becomes a system that reports on itself.
How We Work
Worth being direct about what we are and are not, because this space is crowded with two models that do not solve this problem.
We are not an MSSP. We are not looking to take over your identity operations and manage them indefinitely as a monthly line item. That model creates a dependency rather than a capability, and it leaves you no better off than when you started if the relationship ends.
We are not advisors. We do not deliver a gap assessment, a roadmap, and an invoice, and then leave you to implement it with the same team and the same hours you had before. A report describing what should be automated is not automation.
We build the tools. The collectors, the pipelines, the access review workflows, the integrations into whatever you already run. Working software that belongs to you, in your environment, that your team can operate and modify after we are gone. When the engagement ends you own a capability, not a subscription and not a document.
That is a deliberately harder commitment than either alternative, and it is the one worth making. Identity is the foundation everything else sits on. It deserves to be built properly and it deserves to be yours.
Where to Start
The sequence we recommend, and the one we work through with clients:
- Establish the inventory. Every identity source, every system consuming it, every entitlement path. This is usually more surprising than expected.
- Close the leaver gap. The highest-risk and most tractable problem, and the one assessors probe first.
- Instrument provisioning. Make grants and revocations produce evidence automatically as a side effect of happening.
- Automate review. Replace the periodic spreadsheet with a continuous process that surfaces exceptions.
- Then expand outward. With identity solid, the rest of the catalog gets substantially easier.
How This Goes in Practice
We arrived two weeks before a SOX audit began.
That is too late to automate anything, and we said so on the first call rather than selling a timeline nobody could hit. Two weeks is not a build window. Anyone who tells you otherwise is either going to miss the date or hand you something fragile that gets abandoned the moment the auditors leave.
What they had was a quarter's worth of access reviews spread across spreadsheets. Not one spreadsheet — dozens, in different formats, produced by different people at different times. Some had approval columns filled in, some had approvals recorded in the email thread the file was attached to, and some had been superseded by a later version nobody could definitively identify. The reviews had genuinely happened. Demonstrating that they had happened, to a standard an auditor would accept, was a different problem entirely.
The two weeks before
So we did not build. We triaged.
The work was reconstruction: establishing which review was authoritative for each system, tracing approvals back to a named person and a date, and identifying which populations had no defensible review at all. Where a review was missing or unusable, the honest move was to flag it rather than manufacture something — a reconstructed approval that cannot be traced to a real decision is worse than an acknowledged gap, because an auditor who finds one stops trusting everything else you hand them.
They went into the audit with an organized evidence set, a clear list of what was solid, and a short list of what was not. That was achievable in two weeks. Automation was not.
The six weeks after
The audit completed. Then came the part that mattered more.
One engineer, six weeks, to ingest and audit every identity review the organization held — including the historical mess. Not just to build a process for the next cycle, but to normalize what already existed into something queryable and evidenced.
That meant parsing inconsistent spreadsheet formats into a single structure, reconciling each review against the entitlements that actually existed in the source systems at that point in time, flagging reviews that had approved access which no longer matched reality, and producing a per-system record of who reviewed what, when, and what changed as a result.
The reconciliation is where the value showed up. Several reviews had been approved wholesale — every row marked retain, because approving 400 lines individually under time pressure is not something a busy manager does carefully. Those are the reviews that look complete and prove nothing, and they are invisible until something checks the decisions against the underlying state.
Why it went in that order
Doing it afterwards was not a compromise. It was better.
Building under audit pressure produces bad tools. The deadline forces shortcuts, the scope contracts to whatever satisfies this auditor rather than what the organization actually needs, and nobody has attention for design decisions they will live with for years. The six weeks after an audit are the opposite: the problems are fresh and specific, everyone has just experienced exactly why the current process hurts, there is usually budget attention that was not there before, and there is no date forcing bad choices.
If you are two weeks out from an audit, the right goal is to get through it cleanly with what you have. The build comes after, and it comes with the audit's findings as its requirements document.
One engineer, six weeks, then done. Their team runs it now. That shape is deliberate — you should not have to hire for this, and you should not have to let anyone go when it is finished.
