Security design standards

I write the standard your organisation designs against. Device selection, configuration baselines, network patterns, naming and labelling, documentation requirements, and the acceptance criteria every project has to meet. Once it exists, every future integrator inherits it and every future project starts from a known position rather than from a blank page and a preference.

What inconsistency actually costs

• Every project is priced from scratch, because there is nothing for a bidder to inherit and no basis for comparing one site's cost to another's.
• Support is slower everywhere. A technician arriving at a site has to work out how this one was built before doing anything.
• Spares do not interchange. Six camera models across four sites means six spares, or a delay every time.
• Training does not transfer. Operators moving between sites relearn the system each time.
• Nobody can answer portfolio questions. How many doors, what retention, which sites are on unsupported versions. All of it becomes a survey rather than a lookup.
• Every integrator gets to define your standard for you, one project at a time, in whichever direction suits them.

What the standard contains

A standard that is too thin gets ignored and one that is too rigid gets waived on the first project that does not fit. The useful version is specific where it matters and deliberately silent where it does not.

• Device standards. Approved models by application, with the reasoning recorded, so the list can be revised rather than re-argued.
• Configuration baselines. How devices are hardened, credentialled and configured before they go into service.
• Network patterns. Addressing, segmentation, VLAN structure and the standard topology for a site of a given size.
• Naming and labelling. Devices, ports, doors, cameras, cabling. Dull, and the single thing most likely to be thanked for later.
• Documentation requirements. What every project hands over, in what format, before it is considered complete.
• Acceptance criteria. The tests every install must pass, so completion is demonstrated rather than declared.
• A variance process. How a project departs from the standard when it genuinely needs to, and who signs that off.

The part most standards get wrong

A standard nobody can deviate from becomes a standard everybody ignores. Sites differ for real reasons, and a document that cannot accommodate that gets quietly abandoned within two projects.

The variance process is what keeps it alive. A named route for saying this site needs something different, with the reasoning recorded, means departures are visible and deliberate instead of silent. It also turns the standard into something that improves, because a variance that keeps recurring is telling you the standard is wrong.

Who this is for

• Multi-site owners and portfolios where each location was built differently.
• Institutions and municipalities running repeat capital projects.
• Organisations growing by acquisition, inheriting systems they did not choose.
• Anyone about to run a programme of work who would rather not repeat the last one.

How it runs

Starts with what you already have: a survey of current sites, existing documentation, and the decisions that were made informally and never written down. Most organisations have more of a standard than they realise, held in a few people's heads.

The draft goes through review with the people who have to live with it, because a standard written without operations and IT in the room does not survive contact with either. Scoped and priced in writing before it starts.