Standing up a security program at a company that has never had one

The frame

Most first-time security programs fail because they are organized around an audit, not around a function. The audit becomes the deliverable, the controls become the evidence the audit asks for, and the program never develops the muscle to operate without an external clock driving it. A program that survives needs a different sequence. Identity, then logging, then detection, then policy, in that order. The mechanics are not subtle, but the order is, and the order is what most engagements get wrong.

What "zero" actually looks like

A representative zero-state engagement: a $1B national manufacturing company, 25 U.S. locations including 13 manufacturing plants running OT and ICS, no SIEM, no GRC framework, no central identity authority, and an internal team that owned IT but had never owned security. The first temptation in that environment is to start with a policy document. Resist it. Policy ratifies what already works. Until something works, policy is wishful thinking, and the team that has to operate it knows.

Identity is the load-bearing wall

Identity is not a project; it is the substrate every other control rests on. Without a single source of truth for who exists, who has access to what, and how access is granted and revoked, every downstream control becomes a workaround. At a 25-site manufacturer, that meant consolidating directory authority, rationalizing privileged access, and putting a real provisioning process behind every account. None of it is glamorous. All of it is what makes detection meaningful later.

Logging before detection

A SIEM with no schema, no normalized identity, and no asset inventory is a budget line item, not a capability. Stand up the evidence pipeline first: which sources, which fields, which retention, which trust boundary. Only then turn on detection. A pipeline processing 14 million security events a day across all 25 sites, including the 13 manufacturing plants, is not impressive on its own. It is impressive when the analyst on duty can answer "did this account just do something it does not normally do" in under five minutes. That answer is the product of the pipeline, not the SIEM.

Policy last, because policy ratifies what works

By month four, the first three layers should be functioning, even imperfectly. Policy is now possible. Write the smallest credible set: identity, access, logging, incident response, third-party risk, OT/ICS segmentation. Each policy should describe a control that already exists and a measurement that is already running. Policies written this way get signed quickly and stay signed. Policies written first, in the absence of working controls, get diluted in review and rewritten every twelve months until they mean nothing.

What to defer, and what to never defer

Defer: most tooling consolidation, most maturity-model scoring, most board-level dashboards. These come later and they come easily once the function is real. Never defer: the named owner for every control, the named owner for every evidence stream, and the documented escalation path for every incident category. The named owners are the program. Without them, the rest is a configuration. With them, the program has a chance of surviving the consultant who set it up.