Notes

ISO 27001 implementation when it is your side project

Somebody decided the company needs ISO 27001. A customer asked, or a deal stalled, or the board read something. The work has been given to you, on top of the job you already had, and the available guidance is written either for consultancies selling implementation or for organisations with a compliance department.

These notes are the third thing. Iso 27001 implementation by one person, alongside a day job, in a company small enough that the person writing the risk assessment is also the person who fixes the printer.

What iso 27001 implementation actually asks for

The standard is shorter than people expect and the Annex A control list is longer. That ratio misleads everybody at the start.

Clauses 4 to 10 are the management system: context, leadership, planning, support, operation, performance evaluation, improvement. These are mandatory and they are where certification is won or lost. Annex A is a list of 93 controls you consider, apply where relevant, and justify excluding where not.

The common mistake is to treat the 93 controls as the project and the clauses as paperwork. It is the other way round. An auditor will spend more time on whether your risk assessment method is coherent and whether management review happened than on any individual control, because the controls are evidence of the system working and the system is the thing being certified.

Where the time actually goes

Three things consume most of it, and none of them is the technical work.

The risk assessment, because it has to be defensible rather than complete. Most first attempts are either a 200-row register nobody maintains or a five-row one that fails to explain the controls you selected.

Policies, because writing them is quick and getting them acknowledged, approved and reviewed on a schedule is not.

Evidence, which is the one that surprises people. The controls are usually fine. Proving they operated over a period, with dates and names, is the work, and it cannot be done retrospectively. Evidence you did not capture in March is gone in March.

The one-person problems

Two structural difficulties have no clean answer at this scale, and pretending otherwise wastes your time.

Independence for internal audit. Clause 9.2 requires it and you cannot audit your own work. There are real options and they all involve somebody who is not you.

Segregation of duties. In a company where one person holds identity, endpoints, cloud and compliance, there is no separation to demonstrate. The answer is compensating controls and documenting the position honestly, not inventing an approval workflow where you approve your own requests.

An auditor who works with small companies has seen both and will accept a documented, reasoned position. What they will not accept is a control described as operating when it plainly cannot.

Reading order

These are sequenced, and the order is the order the work happens in. Scope first, because it determines everything downstream and an over-broad scope is the classic self-inflicted wound. Then risk, then the Statement of Applicability, then policies. Internal audit and management review before the certification audit, because Stage 1 will ask for them.

Stage 1 and Stage 2 are one note, and the year two surveillance audit gets its own, because it is the one nobody plans for.

The last five notes are adjacent rather than sequential: compliance automation platforms, customer security questionnaires, how the certifications compare, supplier reviews, and running a business continuity exercise without a conference room.

The book is the long version of all of this, written from taking a roughly 40-person SaaS company through ISO/IEC 27001:2022 single-handed.