ISO 27001 for small teams is a different job from ISO 27001 in a large company, even though the standard is the same. A team of five to thirty people does not have a security department, so one person runs the system next to their normal work. The aim here is to show how to do that in about 90 days of focused effort: who does what, what to scope, what order to work in and what you can honestly leave out. For the clause by clause list, see our ISO 27001 checklist for small businesses. This article is the plan around it. It follows ISO/IEC 27001:2022 and is general guidance, not advice from a certification body.
Decide whether you need it
ISO 27001 certifies your information security management system (ISMS). It is worth the effort when customers, tenders or partners ask for it, or when you hold data for others and want a clear way to run security. It is not a legal requirement in itself, and it does not make you secure. It shows that you manage security by risk, with records, and that an independent body checked.
Before you start, ask your three biggest customers what they actually want. Some accept a completed security questionnaire. Some want ISO 27001, others SOC 2, which is a different report from an audit firm, not a certificate against an international standard. If nobody asks, a lighter set of good practices may do for now.
Who does what in a small team
- Top management (the owner or a director) approves the policy, scope and risk acceptance, joins the management review and gives time. Auditors interview them.
- The ISMS owner is one named person who keeps the system running. It need not be a full time job, and in a small company it is often the technical lead or operations manager.
- Risk owners are the people responsible for each asset or process, who accept the remaining risk.
- Everyone knows the policy, completes awareness training and reports incidents.
- An internal auditor who is not auditing their own work. In a tiny team that may be an outside person for one day.
Choose a small, honest scope
The scope says which products, locations, people and systems the ISMS covers (clause 4.3). Smaller is allowed if it is real and matches what customers care about. A software team may scope the one product it hosts and the staff who work on it. You must still say how you depend on what is outside the scope, such as the cloud host and the office network.
A scope that is too wide means more controls to evidence. One too narrow may not satisfy the customer who asked. Write the sentence you would give a customer and check it is true.
A 90 day plan
This assumes one person spending roughly a day or two a week, and a team that already uses sensible tools. If you start from nothing, expect longer. Treat the weeks as a sequence, not a promise.
Weeks 1 to 2: set the frame
- Ask customers what they need, set the scope and write the context: issues and interested parties (clause 4).
- Have top management approve an information security policy (5.2) and name the ISMS owner (5.3).
- Make an asset list: laptops, phones, cloud services, code repositories, key data sets (Annex A 5.9).
Weeks 3 to 5: risk
- Choose a simple method: rate likelihood and impact on a scale of three or five, and fix the level you accept (6.1.2).
- List risks against your assets in a risk register. Twenty real risks beat a hundred generic ones. See how to run a risk register.
- Decide the treatment for each risk, and have risk owners approve the plan and accept what remains (6.1.3).
- Draft the Statement of Applicability: all 93 Annex A controls, with included or excluded, why, and whether in place.
Weeks 6 to 9: put controls and records in place
Focus on the controls your risks point to, which for a small cloud based team are usually these:
- A second factor and single sign-on or a password manager on every account that offers it (Annex A 5.15, 5.17, 8.5).
- Disk encryption, screen locks and updates on laptops and phones (7.9, 8.1, 8.8).
- Backups with a restore test you record (8.13).
- Access rights reviewed when people join, change role and leave (5.18, 6.5).
- A supplier list with the security terms of each cloud provider checked (5.19 to 5.22).
- An IT security policy, an incident response plan and a place to log incidents (5.24 to 5.27).
- Awareness training with a record per person (6.3, 7.3).
- A way to track changes, vulnerabilities and logging proportionate to your systems (8.8, 8.15, 8.32).
Everything you do has to leave a trace: a ticket, a screenshot, a signed list, a dated review.
Weeks 10 to 12: check and review
- Run the internal audit across the whole ISMS, with a written report and findings (9.2). Use the internal audit plan and read your first internal audit.
- Hold the management review with the required inputs and recorded decisions (9.3), using management review minutes and this one afternoon guide.
- Fix findings with corrective actions that address the cause (10.2).
At the end of this you are ready to book the audit. Certification bodies want to see the system running, so a few weeks of records before the audit is the minimum, and several months is common.
The certification route and what it costs
You choose an accredited certification body and agree scope and audit days. Stage 1 reviews your documented information and readiness, and stage 2 audits that the system works through interviews and samples. The certificate usually lasts three years with a surveillance audit each year, and then recertification. Audit time is planned from the number of people and the complexity in scope, following ISO/IEC 27006, so quotes differ. We do not publish audit prices because they are quoted case by case: ask two or three bodies for a written quote, including the surveillance years.
The other costs are your own time, any consultant days, a copy of the standard, and tools. A spreadsheet is enough for the ISMS of a small team. Platforms that connect to cloud accounts, such as Vanta, Drata or Secureframe, can save evidence gathering when most of your work happens in those tools. Check each on its own pricing page, because most show plans without prices.
