When you are starting a security program from nothing, sequence matters more than completeness. The first ninety days are not about covering every risk. They are about learning what you actually have, closing the doors that are standing open, and leaving behind something that keeps working after the attention moves on.
I have built this from scratch and I have inherited it half-finished, which is the more common situation. The half-finished version usually failed for the same reason every time. It started with a framework instead of an inventory, and nobody could say what the controls were supposed to protect.
Days 1 to 30: find out what you have
You cannot protect what nobody has written down, and in most organizations the honest answer to “what do we have” lives in three or four people’s heads. The first month is spent getting it out of there.
- Assets. Servers, endpoints, network devices, cloud tenants and the things nobody remembers owning. The gap between the asset list and the vulnerability scan target list is one of the most reliable findings in any environment, and it is usually a surprise to everyone.
- Identity. Who has an account, who has a privileged one, and which accounts belong to people who left. This is often the fastest measurable win available.
- Data. Where the material that would hurt you actually lives. Not a full classification exercise, just the handful of systems that carry customer, financial or contractual obligation.
- Obligations. What you have already promised, in customer contracts, insurance attestations and any regulation that applies. These set your real deadlines, and they are frequently earlier than anyone expects.
Resist scoring anything this month. A maturity score produced before the inventory is stable measures your paperwork rather than your posture.
Days 31 to 60: close the doors that are standing open
The second month is for the small number of changes that remove the most exposure per hour spent. In almost every environment, it is the same short list.
- Multifactor authentication on email and remote access. Business email compromise remains the most common way money leaves a company, and this is the single control that most reduces it.
- Individually assigned privileged accounts. Shared administrator credentials turn every investigation into guesswork. Assigning them by name is cheap and it closes an audit finding you were going to get anyway.
- A restore you have actually performed. Pick one important system and recover it to a test environment. What you learn in that afternoon is worth more than a year of backup reports.
- Patching with a deadline attached. Not a perfect program, just a stated window for critical fixes and a way to see what missed it.
Four items, and each one converts into a sentence a board or an insurer can act on. That matters more than it sounds, because this is the month where the program starts producing evidence rather than intentions.
Days 61 to 90: make it durable
Everything above can quietly come undone the moment the person driving it gets pulled onto something else. The third month is about making the work survive that.
- Write down what you decided. A short policy set that reflects what you are actually doing, not an aspirational document borrowed from somewhere else.
- Name owners. Every control gets a person, not a team. Teams do not get calendar reminders.
- Pick three measures and baseline them. A maturity score against a recognized framework, time to remediate critical findings, and one human-factor measure such as phishing failure rate. Same three every quarter.
- Schedule the first review. Put the ninety-day report on the calendar before you need it, with the audience named.
What to deliberately not do yet
New tooling, mostly. The instinct to buy a platform in month one is understandable, and it almost always outruns the ability to operate it. A detection product with nobody watching it is an expense with a dashboard.
Also worth deferring: full data classification, a formal risk register with quantified loss modeling, and anything requiring a committee. None of these are wrong. They are second-year work, and starting them early is one of the more common ways a promising program loses its first year.
That is not a judgment on their value. A mature program needs all of them eventually, and the teams that push for them early are usually the ones who care most. The reason to wait is sequence, not worth.
The ninety-day report
End the quarter with one page: where we stand, what changed, what I need from you, and what we are accepting for now. If you can write that page honestly at day ninety, the program exists. If you cannot, you have learned something more useful than any framework would have told you.
If you are at the start of this and want the inventory and the scored position without spending the first month building them yourself, that is exactly what a Security Maturity Snapshot produces. Tell me where you are starting from and I will tell you what the first ninety days should hold.