Compliance When You’re the Only One Doing It

Almost every published guide to building a security programme assumes a security team. Most companies that need one do not have a security team. They have one person, doing this alongside something else — a Head of Engineering, a CTO, an ops lead, occasionally a first compliance hire six weeks into the job with a certificate deadline already set.

This is written for that person. Not a lighter version of the enterprise playbook — a different order of operations, built around the constraint that actually binds: there is one of you, and compliance is not your only job.

The first decision: scope down, hard

Scope is the only lever that changes the size of the work, and it is the one most teams decline to pull because narrowing feels like cheating. It is not. ISO 27001 explicitly expects you to define the boundary of your ISMS, and auditors are entirely comfortable with a scope that covers the product and the people who build it rather than the whole company.

A scope statement that names your platform, your production environment and the teams that touch it is defensible, auditable, and perhaps a third of the work of one that sweeps in the marketing department, the office, and a subsidiary in another country. Write it narrow. Widen it later if a customer ever asks — in practice, almost none do.

Do these five things before anything else

In order. Each one reduces the cost of everything after it.

The conventional order puts policies first, because policies are what consultants deliver. For a team of one it is exactly backwards: you end up maintaining a document set describing controls you have not built, and every one of those gaps surfaces at Stage 2.

Automate evidence or lose your weekends

This is the single highest-leverage decision available to you. Roughly half the work of maintaining a certification is producing evidence that a control operated — access reviews, patch status, backup tests, training completion, change approvals. Done by hand it is a permanent tax, paid in screenshots, forever.

Connect the systems that already know the answer: your cloud, your identity provider, your endpoint tooling, your code repository, your HR system. Each connection turns a recurring manual task into a continuous one. A useful rule: if you will need the same evidence more than twice, wire it up instead.

Map once, answer many times

The second framework is where a one-person programme either scales or collapses. A customer asks for SOC 2 having already accepted your ISO 27001. A financial services prospect raises DORA. Someone in Germany asks about NIS2.

These standards overlap heavily. Access control, change management, incident response, supplier management and business continuity appear in all of them, phrased differently. If your evidence is filed by framework, you rebuild it each time. If it is filed by control, with mappings out to each standard, the second framework is a mapping exercise rather than a project.

Get this right early. Restructuring an evidence library after two years is far worse than setting it up correctly at the start.

The things you cannot do alone — and what to do about them

• The internal audit. ISO 27001 clause 9.2 requires auditor independence, and you cannot audit work you performed. Use a peer from another team, swap with a friendly company, or buy a few days of contractor time. It is the cheapest external spend in the whole programme.
• Penetration testing. Needs to be external and needs to be real. Budget for it annually; it is the item enterprise buyers check most reliably after the certificate itself.
• Management review. Clause 9.3 requires leadership involvement, which means an actual meeting with actual decisions, minuted. Put it in the calendar quarterly or it will not happen.
• The awkward conversations. Someone will need to tell engineering that shared admin credentials stop now. That is a leadership conversation, not a compliance one — get your sponsor to have it.

Protect your time from the questionnaire queue

Security questionnaires will eat your week if you let them. They arrive unpredictably, always urgently, always attached to revenue, and they are the reason one-person programmes stall.

Three defences, in order of effectiveness. Build an answer library the first time you answer anything, so no question is ever answered twice from scratch. Publish a Trust Centre with your certificate, sub-processor list, security overview and a documented request route, so the easy 60% of questionnaires never reaches you. And route everything through one intake — not your personal inbox, not a Slack DM from an account executive.

A realistic first year

• Months 1–2: scope, asset and data inventory, access and MFA cleaned up, tooling connected.
• Months 3–4: risk assessment, gap analysis against the control set, remediation plan with owners and dates.
• Months 5–7: close the gaps. This is the long part and it is mostly engineering work, not paperwork.
• Month 8: policies written to describe what now actually happens. Internal audit. Management review.
• Months 9–10: Stage 1, then Stage 2. Expect minor non-conformities; almost everyone gets some.
• Ongoing: roughly a day a week to keep it alive. Less if the evidence collects itself, considerably more if it does not.

What to automate first, in order

Not everything is worth wiring up, and the order matters because early wins buy you credibility for the harder asks. Ranked by hours saved per hour invested:

Handling the pushback

The hardest part of a one-person programme is not the standard. It is that you have responsibility without authority, and every control you need touches someone else’s work.

Three patterns that help more than arguing:

Bring the customer, not the clause. “Annex A.8.2 requires privileged access restriction” loses. “The deal we are trying to close asked specifically about shared admin accounts, and we currently have four” wins. Engineers are not resistant to security; they are resistant to abstraction.

Ask for the smallest version. Do not propose a quarterly access review process to a team with no process. Ask for one review, this month, of one system. The process is easier to sell once it has happened once and taken forty minutes rather than the day everyone feared.

Get the sponsor to own the unpopular decisions. You should not be the person telling a senior engineer their workflow is changing. Your job is to make the case and hand it to whoever has the authority. If you do not have a sponsor at leadership level, that is the first thing to fix — clause 5 of the standard requires it anyway.

What to say no to

Capacity is the binding constraint, so declining is a core skill. Things it is usually correct to refuse, at least in year one:

• A second framework before the first is certified. Map it, plan it, but do not run two certification projects at once with one person.
• Bespoke customer security addenda that contradict your standard terms. Offer your DPA and your Trust Centre; escalate genuine exceptions to leadership with the cost attached.
• Certifying scope you do not need. "While we are at it, let us include the whole group" is the single most expensive sentence in this process.
• Tooling that does one thing. Every point tool is another integration, another login, another evidence silo you personally maintain.
• Ad-hoc questionnaire requests arriving by Slack DM. Route or refuse; there is no third option that survives.

When one person stops being enough

There is no headcount number, but there are signals. When two or more of these are true, the programme is being rationed rather than run:

• You are maintaining three or more frameworks with meaningfully different evidence.
• Questionnaires consistently take more than a day a week.
• Remediation items are ageing because nobody has time to chase owners.
• You are the single point of failure — nobody else could pass the surveillance audit if you left.
• Incidents are being handled by whoever notices, because there is no rota.

The usual first hire is not another generalist. It is either someone to own questionnaires and customer assurance — which is where the revenue pressure sits — or a security engineer to own the technical controls, leaving you the management system. Which one depends on whether your bottleneck is sales or engineering.

The thing worth remembering

A one-person programme that is narrow, automated and honest beats a sprawling one that exists mostly on paper. Auditors are not fooled by volume and customers do not read your policies — they check that the certificate is real, that someone answers questions competently, and that the control they care about actually works.

You can do that on your own. You cannot do it on your own while collecting screenshots by hand.