You’re not Microsoft. You don’t have a Security Operations Centre, a CISO, and three teams arguing about zero trust on a Tuesday. 

You have…you. 

Maybe a five‑person agency on Slack, a handful of SaaS tools, and a client waving a contract that says “ISO 27001‑certified supplier only, please”. Suddenly a standard written with banks and governments in mind is sitting in your lap. 

This is where most small teams panic. They google “ISO 27001 documentation pack”, download 120 templates, and end up with a 50‑page access control policy they have neither the time nor the will to enforce. The cruel punchline? You don’t fail the audit because you’re small. You fail because you pretended to be big. 

As an unaccredited certification body that spends its days with one‑person IT “departments” and lean agencies, here’s the good news: ISO 27001 is survivable when you stop copying the enterprise costume and start tailoring it to the body you’ve actually got. 

Appropriate security, not heroic cosplay 

ISO 27001:2022 is blunt in its own way. It cares about two things above all: have you thought about your risks, and can you prove what you said you’d do is actually happening. 

It does not say: 

• “Thou shalt have a 24/7 SOC.” 
• “Thou shalt own a data centre.” 
• “Thou shalt write a novel’s worth of policy per control.” 

What it does say is: 

• You shall define the scope of your ISMS. If that’s “our email, our shared drive, our SaaS stack, and the laptops we work on”, that’s fine. 
• You shall assess risks and treat them based on likelihood and impact. 
• You shall implement “appropriate” controls – not every control, every time. 

For a one‑man band or a five‑person remote crew, “appropriate” rarely looks like a corporate textbook. It looks like: 

• MFA on everything that matters. 
• Disk‑encrypted laptops that lock themselves when you walk away. 
• Backups that actually restore when you test them. 
• Access rights that don’t leave ex‑freelancers lurking in your production tools. 

The point of ISO 27001 isn’t to turn you into Microsoft. It’s to make your current size less fragile. 

Scope: draw a small, honest circle 

Big organisations love sprawling scope diagrams. You don’t need one. 

Your first survival move is to draw the smallest honest circle around the information you must protect to meet your clients’ expectations and legal duties. 

For a micro‑agency or SaaS start‑up, that’s usually: 

• Your primary domain and email (e.g. Microsoft 365 or Google Workspace). 
• Your key SaaS platforms (project management, CRM, code repos, cloud hosting). 
• The devices used to access them (company laptops, maybe a few mobiles). 
• The core data you process: client documents, source code, designs, personal data. 

You do not have to include: 

• Your personal Netflix account. 
• Your side‑project blog hosted on an ancient shared server. 
• Every phone someone has ever opened Slack on once at a conference. 

Write it down as your ISMS scope in a short, clear paragraph. That paragraph becomes the fences of your field. Inside it, you’ll go deep. Outside it, you’ll be sensible but you won’t lose sleep. 

If you try to boil the ocean, you’ll end up with lukewarm policy soup. 

Risk assessment: one spreadsheet, not a PhD 

Clause 6 is the foundation of ISO 27001: work out your risks, decide what to do about them, prove you’re doing it. 

You don’t need a risk committee. You need one honest afternoon with a spreadsheet. 

Start with three columns: 

• Asset: what you care about (client data in OneDrive, your billing system, your code repo). 
• Threat / weakness: what could go wrong (lost laptop, phishing email, rogue plugin, mis‑configured bucket). 
• Impact if it happened: mild annoyance, major embarrassment, existential. 

Then add: 

• Likelihood: gut‑feel for now, refined over time. 
• What we’re already doing: MFA, backups, encryption, access limits, vendor controls. 
• What we’ll add: the extra controls that move you from “risky” to “reasonable”. 

That’s it. Don’t chase perfection. Aim for traceable decisions: 

• “We don’t store production data on local machines. So stolen laptop = low impact, but we still encrypt disks because it’s easy.” 
• “We rely on a single cloud provider for hosting. If they go down, we’re offline. So we’ll at least define an RTO and a basic recovery plan.” 

When an auditor turns up, they’re not checking whether you predicted every storm. They’re checking whether you own the weather that actually hits you. 

Policies that fit on one screen 

Most small teams break ISO 27001 not at the control level, but at the word count. 

The standard explicitly lists the few documents you must have: scope, policy, risk assessment and treatment methods, Statement of Applicability (SoA), objectives, evidence of competence, operational planning, risk results, audit and review evidence. Everything else is flexible. 

So your job is to write as little as you can that still: 

• Sets clear expectations. 
• Can be read in one sitting. 
• Matches what people really do. 

Some examples. 

Information Security Policy 

• One page. 
• Says what you protect, why, and the core principles (least privilege, need‑to‑know, secure by default). 
• Signed by the person who actually makes decisions (which might also be you). 

Remote Working Policy 

You don’t need to describe every kitchen table. You do need to say: 

• Use company‑managed or approved devices. 
• Enable disk encryption, automatic updates, screen lock after X minutes. 
• Don’t share devices with family where client data is accessible. 
• Use VPN or secure access when on unknown networks. 

Two pages, tops. 

Access Control Policy 

Forget “segregation of duties between development and production teams” if you are both. Instead: 

• Every user has unique accounts. 
• MFA is mandatory on identity provider and key SaaS. 
• Admin rights are limited to named people. 
• Access is removed on the day someone leaves. 

If your policies describe a world you don’t inhabit, you’ve created fiction, not control. 

Controls you can actually run on a Tuesday 

Annex A now has 93 controls across four themes: organisational, people, physical, technological. You are not expected to implement all of them blindly. 

The Statement of Applicability (SoA) is your menu. It lists: 

• Each control. 
• Whether it’s applicable. 
• If not, why not. 
• If yes, how you’ve implemented it. 

For a one‑man band, some common‑sense outcomes: 

• Physical controls: you probably don’t have an office with perimeter fencing or CCTV. You do have a laptop at home. “Physical security” becomes: don’t leave it in the car, lock your screen, don’t work on open public Wi‑Fi with sensitive data. 

• Clean desk: if your “desk” is a rotating set of cafés and a coworking hot‑desk twice a week, a classic clean‑desk policy is theatre. Instead, you commit not to print client data unless strictly necessary and to shred or securely store anything you do print. 

• Supplier security: you’re not running on bare metal; you live in SaaS. Your “supplier policy” can be a one‑page checklist you run before adopting a service: 

• Do they claim ISO 27001 or SOC 2? 
• Do they offer a DPA and data‑location clarity? 
• Do they support SSO and MFA? 
• Do they have uptime and incident‑reporting commitments? 

Security isn’t measured by how many controls you name. It’s measured by how many you can prove are in use, day after day. 

Incident management: from panic to pattern 

When something goes wrong – a lost phone, a dodgy email, a suspicious login – big organisations have war rooms, ticketing systems and crisis scripts. 

You can start with a tiny, brutally simple incident process. 

Three moving parts: 

1. How you spot trouble

• Security alerts from your identity provider and SaaS tools.
• A team member saying, “This email looks odd” or “I think I clicked something”. 
• Device loss or theft. 

2. Where you shout 

• A dedicated channel: a Slack room, Teams channel, or yes, even a WhatsApp group named something more grown‑up than “panic”, but serving the same purpose. 
• Rules: report fast, don’t cover up, no blame for raising the flag. 

3. How you record and learn 

• A simple incident log: date, what happened, what you did, follow‑up. 
• Periodic review of that log (even if “periodic” is you, on a Friday morning) asking: what does this pattern say? What control do we tweak? 

ISO 27001 wants to see that you: 

• Identify incidents. 
• Respond. 
• Learn and improve. 

It doesn’t care if your “system” started life as a spreadsheet and a group chat, provided it’s consistent and gets upgraded as you grow. 

You as “top management” and “ISMS manager” 

In a one‑person or tiny company, Clause 5 (leadership) and Clause 7 (support) all point to the same human: you. 

That can feel ridiculous on paper: 

• “Top management commits to…” 
• “Management shall ensure…” 
• “Responsibility and authority shall be assigned…” 

But it’s actually tidy. There is no confusion about who’s on the hook. 

So you: 

• Write a brief roles and responsibilities note that says, in plain language, that you wear both hats: leadership and implementer. 
• Set achievable security objectives: “Zero critical incidents that affect client deliverables this year”, “100% of users with MFA”, “Access removed within 24 hours of someone leaving”. 
• Schedule a quarterly management review – even if it’s you with a cup of tea and your notes – to ask: 

• What changed in our business? 
• What changed in our risks? 
• Which controls felt painful or pointless? 
• What do we stop, start, or tweak? 

There’s no committee. There is a cadence. That’s what the standard is really after. 

Evidence over theatre 

If an auditor visited you tomorrow and you had to defend your security with one artefact, it shouldn’t be your policy folder. It should be evidence that your controls live in the real world. 

For a small team, that looks like: 

• Screenshots of MFA enforced on your identity provider and key apps. 
• Exports from your user directory showing leavers are actually removed. 
• Device‑management screenshots (encryption, patching, screen‑lock policies). 
• Training records: short, regular awareness sessions, not annual box‑ticking epics. 
• That incident log, showing how you handled “little scares” before they became headlines. 

When we coach one‑man bands through ISO 27001, we keep repeating one line: 

If you can’t produce proof in two clicks, you probably don’t actually do it. 

So build the system around what you can easily show. 

Certification when you’re tiny: picking your battles 

Because we’re unaccredited, we don’t sell you a badge. We help you get ready for someone else’s. That makes us unusually free to say: sometimes full certification is overkill; sometimes it’s exactly the lever you need. 

Good reasons to go the whole way: 

• A key client or framework literally requires an ISO 27001 certificate. 
• You handle data that would seriously harm people or your business if leaked. 
• You want to differentiate in a crowded B2B space. 

Good reasons to pause or slim down: 

• No one has asked for a certificate yet, but everyone asks security questions. 
• You’re pre‑revenue or very early‑stage and cash is tight. 
• You’re trying to stabilise your basic operations first. 

In those cases, you can still: 

• Implement the architecture of ISO 27001 (scope, risks, controls, incidents, reviews) without booking an external audit yet. 
• Build a security pack you can send to prospects: your policy, high‑level SoA, overview of controls, maybe a short internal audit summary. 

Then, when the day comes that someone says “we need the certificate”, you’re not starting from zero. You’re finishing a job you began sensibly. 

Simplicity as a security control 

The harsh truth for small teams is this: complexity is a security risk dressed up as sophistication. 

Every extra page you add to a policy is another place reality can drift away from paper. Every new tool you bolt on is another identity store, another potential mis‑configuration. 

ISO 27001, when read with small‑team eyes, is surprisingly sympathetic: 

• Know your world. 
• Protect what actually matters. 
• Prove you do what you say. 
• Adjust when the world changes. 

You don’t win by imitating Microsoft’s stack. You win by building a minimal, truthful system that fits your size today and can stretch as you grow. 

So if you are the only IT person, or the founder who also fixes the printer and revokes access on Fridays, don’t start with a template pack and a headache. 

Start with a scope sentence, a risk spreadsheet, three lean policies, MFA everywhere, and a quiet decision to treat information security as just another part of how you run a grown‑up business. 

The badge, if you decide you need it, comes later. The discipline starts now. Need help? Let’s talk: