Building a Control Library From Scratch: Where to Actually Start When You Have Nothing Written Down

Most small MSPs and most of their smaller clients don't have a control library. They have practices — things that happen, more or less consistently, in someone's head or in a folder of half-updated documents — and when a client, insurer, or prospective enterprise customer asks for a control library, the honest answer is that one doesn't exist yet. Building one from a blank slate is less intimidating than it looks, but only if it's built in the right order.

Don't start with a framework. Start with what's actually running.

The instinct when asked for a 'control library' is to open a framework document — NIST CSF, CIS Controls, SOC 2's trust services criteria — and start filling in blanks for controls that don't exist yet. That produces a library full of aspirational entries and almost no evidence, which fails the first real audit worse than having no library at all. The better starting point is an inventory of what's actually running today: which systems hold sensitive data, who has access to them, what already gets logged, what already gets backed up. The framework gets mapped onto that reality afterward, not the other way around.

The order that actually works

• Inventory first: systems, data locations, and who has administrative access — this alone usually surfaces gaps nobody had named out loud
• Identify the handful of controls already happening informally — MFA on the email platform, automatic patching on endpoints, a backup job that runs nightly — and document those as the first 'implemented' entries with real evidence, building early momentum instead of starting from zero
• Mark the gaps honestly as 'planned,' not 'implemented,' even when it's embarrassing — a control library that lies to make the current state look better than it is defeats its own purpose the first time someone checks
• Pick one framework to map against rather than trying to satisfy five simultaneously — most frameworks overlap on the majority of their substance, so a well-evidenced control library built against one maps onto others with incremental work, not a rebuild

The trap of over-scoping on day one

A common failure mode is trying to build full coverage of every framework a client might eventually need before showing any of it to anyone. That guarantees the library never ships, because framework coverage sprawls faster than a small team can document it. A library with ten controls that are genuinely implemented and evidenced is more useful — to an auditor, an insurer, or the MSP's own incident response — than a library with two hundred controls that are aspirational entries with no evidence behind them.

A control library's first job isn't to look complete. It's to be true.

The three-state model — implemented, partial, planned — exists in Nexus's compliance module specifically because a control library built honestly always looks unfinished for a while, and a tool that only has room for 'done' pressures people to mark things done before they are. Starting from zero with that structure in place means the library is defensible from the first control entered, rather than needing a rewrite once someone finally checks the evidence behind it.