May 7, 2026

Building an ISMS From Scratch: A Practitioner's Playbook

When I was asked to build an information security management system for a new entity entering the healthcare technology space, there was nothing to inherit. No policies, no risk register, no security documentation of any kind. Just a business that needed to be operational and compliant — quickly.

This isn't a rare situation. PE-backed acquisitions, new subsidiaries, companies that grew fast and never formalized security — a lot of organizations reach a point where they need a real ISMS and don't know where to start. Here's how I approached it.

Pick a Framework First and Let It Do the Heavy Lifting

Before writing a single policy, decide what you're building toward. For us, it was ISO 27001. We already maintained an ISO 27001-aligned ISMS at our parent organization, so familiarity with the framework was a significant advantage — but even without that, ISO 27001 gives you a complete structural blueprint — scope definition, risk methodology, control selection, management review. If you follow the framework honestly, you don't have to invent your organizational model.

NIST CSF is another strong option, especially in the US. The important thing is to commit to one framework as your skeleton and layer additional requirements (HIPAA, SOC 2, whatever your industry demands) on top of it. Trying to satisfy multiple frameworks simultaneously without a structural anchor leads to a pile of disconnected documents that no one maintains.

Risk Assessment Before Policies

The instinct is to start writing policies. Resist it.

Your risk assessment drives everything downstream — which controls you implement, how you prioritize spending, what your policies actually need to say. If you write policies first, you're guessing at what matters. If you assess risk first, your policies reflect your actual environment.

I used an approach based on ISO 27005: identify assets, identify threats and vulnerabilities, assess likelihood and impact, calculate risk scores, determine treatment. It doesn't need to be elaborate — a well-structured spreadsheet works for a first pass. What matters is that you have a defensible methodology and a risk register you can point to when someone asks why you made the choices you made.

Build the Policy Library in Layers

Once you know your risks, build policies in priority order. Core policies first:

  • Information Security Policy (your umbrella document)
  • Access Control
  • Incident Response
  • Acceptable Use
  • Data Classification and Handling

Then expand into the areas your risk assessment highlighted and your compliance obligations require — business continuity, vendor management, change management, encryption, physical security.

A practical tip: write policies that reflect what you actually do, not what you aspire to do. Aspirational policies create audit findings. Honest policies create a baseline you can improve. I've seen organizations write beautiful policies that describe a security program three years more mature than what they're operating. That's a liability, not an asset.

Roughly 15 documents covered the full scope for our environment. Your number will vary, but don't over-engineer it. A policy that exists, is followed, and is reviewed annually is worth more than a comprehensive library that sits on SharePoint.

Design Infrastructure With Security Built In

If you have the luxury of standing up IT infrastructure in parallel with the ISMS — and in a greenfield scenario, you often do — take advantage of it. Security decisions made at the architecture level are dramatically cheaper than ones retrofitted later.

This means identity and access management designed from day one, network segmentation that reflects your data flows, logging and monitoring that actually gets reviewed. These aren't separate "security projects" — they're how you build infrastructure if you're thinking about it correctly.

HIPAA as an Overlay, Not a Separate Program

For healthcare-adjacent organizations, HIPAA compliance is often treated as its own standalone effort. It doesn't have to be. If your ISMS is built on a solid framework like ISO 27001, most HIPAA Security Rule requirements map directly to controls you've already implemented.

The gaps are typically in privacy-specific areas: breach notification procedures, Business Associate Agreements (BAAs), workforce training on PHI handling, minimum necessary access. Layer those on top of your existing ISMS rather than building a parallel program. One program with framework-specific overlays is maintainable. Two parallel programs is a staffing problem.

The Ongoing Reality

Building the ISMS is the visible milestone, but the real work is what happens after. Annual policy reviews, risk register updates, management review meetings, internal audits — the operating rhythm that keeps the program alive. Build that rhythm from day one, not after your first external audit.

The organizations that struggle with compliance aren't usually the ones with weak controls. They're the ones that built something once, declared victory, and stopped maintaining it.