ISO 27001 small team roles and segregation of duties

Can a small team meet ISO 27001 roles and segregation of duties?

A small team can meet the roles, oversight and competence requirements of ISO 27001 if top management keeps its clause 5 duties and every conflicting duty is identified and managed under control A.5.3. Headcount does not decide the outcome on its own. What matters is whether a named leader owns the policy and the ISMS, whether each security task has a clear owner, and whether the people who approve access, change systems and handle money are kept apart or, where that is impossible, have their activity reviewed by someone else. The exact answer depends on a few facts about your company. Ask who holds security, IT administration and finance access today, and whether any one person can create a user, approve that user's access and release a payment. Ask whether the ISMS is scaled to your size, which the standard's introduction expects, and whether the policies and roles you write are ones your team will actually run. A two-person company and a fifteen-person company face different questions about compensating reviews, and the record of those reviews is what an assessor will test.

Your organization owns its controls. A consultant or implementation partner can draft the roles matrix, set up the access and change records, and prepare the evidence, but the people named in those records must do the work and sign off the decisions. Top management's involvement under clause 5, including the policy and the assignment of responsibilities, is audited even when outside help is used. Only an independent certification body issues the certificate, so any plan should be checked against the certification body's own requirements before you commit. Before you engage anyone, write down the roles, list every person who holds more than one of them, and record how each overlap is covered, such as a second approver or a periodic review of privileged access under A.8.2. Confirm with your intended certification body how it will test competence for people in each role, and ask your implementation partner which of these records it will prepare and which must be produced by your own staff.

Which clause 5 duties top management keeps even in a small company

Clause 5 of ISO/IEC 27001:2022 puts information security responsibility on top management, whatever the size of the company. In a small team, the founder or CEO usually holds these duties personally, and the auditor will look for evidence that they were carried out, not just that a consultant wrote the documents.

Leadership and commitment (5.1)

Clause 5.1 asks top management to show active commitment to the ISMS, including making sure its objectives are set and that it is integrated into business processes. For a small company, this means the founder or CEO attends management reviews, asks about security risks in planning, and is named as the sponsor. The auditor will ask who did this and when, so keep dated minutes, calendar entries or decision logs that show the leader's involvement.

The information security policy (5.2)

Clause 5.2 requires a documented information security policy that is appropriate to the organization's purpose and approved by top management. A small company may have a short policy, but the approval must come from a leader who holds authority, not from an external adviser. Check that the approver's name, the approval date and the version history are recorded, and that staff can access the current version.

Roles, responsibilities and authorities (5.3)

Clause 5.3 requires top management to assign responsibility and authority for ensuring the ISMS conforms to the standard and for reporting how it performs. In a team of a few people, one person may hold several of these roles, so the assignment should be written down with the name of each role holder. Confirm that every role has a named owner and that the owner knows what they are accountable for.

Allocating roles under A.5.2

Annex A control A.5.2 asks the organization to define and allocate information security roles and responsibilities according to its needs. The control does not prescribe a fixed org chart, so a small company can allocate the same person to access reviews, incident handling and supplier checks, provided the allocation is documented. Record who holds each role in a simple register and update it when people join or leave.

Policy approval and objectives

Top management is expected to set information security objectives and make sure resources are available to meet them. For a founder, this means choosing a small number of measurable goals, such as completing access reviews on a set schedule, and approving the budget for tools or training. Ask your implementation partner to help draft the objectives, but confirm that leaders can explain them and that the decisions appear in dated records.

Management review and resources

Clause 9.3 of the standard requires management reviews of the ISMS at planned intervals, and clause 7.1 requires the organization to provide the resources the ISMS needs. In a small company, the founder should hold a recorded review that covers audit results, incidents and open risks, and should approve resources such as staff time, tools or outside testing. The review minutes and resource decisions are often the first evidence an auditor asks to see.

How A.5.3 segregation works when one person holds several roles

A.5.3 asks the organization to separate conflicting duties and conflicting areas of responsibility, so that no single person can commit and conceal fraud, error or a bypass of a security control. In a three-person company this rarely means hiring to separate roles. It means identifying which combinations of duties are dangerous, deciding which ones cannot be avoided, and documenting the measures that reduce the risk in those cases. Start with a simple test: list every production-affecting action (write code, approve a change, deploy, hold administrator rights, approve payments, export customer data) and mark any person who can perform two steps in the same sequence without anyone else seeing it.

Illustrative example: in a three-person company, one engineer writes code, approves her own merge, deploys to production and holds the production administrator account. That single person can push an unreviewed change that also disables the logging that would reveal it. The conflict cannot be removed without adding people, so the organization has to reduce it. Reasonable compensating measures include peer review of changes before merge, which the organization should tie to the change management control A.8.32, and logging of all privileged access under A.8.2 so that administrator actions are attributable and reviewed. Periodic access reviews under A.5.18 and A.5.15 show that rights are still needed, and a separate approval step for payments or customer data exports, performed by a second person or a named approver, covers the financial and data risks.

The organization decides how much residual risk it accepts, and it must record that decision. Write the conflict, the compensating measures, the person accountable for reviewing them and the review frequency in the risk assessment and the Statement of Applicability. Ask your certification body during planning how it expects a small team to evidence these measures, because the auditor will look for proof that the controls operate, such as merge records, log samples and signed access reviews, not only a written statement that they exist. Confirm with your own engineers which accounts can reach production, since shared or forgotten administrator accounts are the most common gap.

Ways a small company can split duties and when each fits

This table compares four ways a small company can cover ISO 27001 roles when people hold several jobs at once. Read each row for who carries the conflict, what an auditor will ask to see, the recurring effort, and what breaks if the person leaves. The main takeaway is that a small team can meet A.5.3 with documented compensating controls, but the evidence burden grows as the number of overlapping roles grows.

Option	Who carries the conflict	What the auditor will ask for	Recurring effort and departure risk
Founder holds several roles with compensating controls	One founder approves access, writes policy and runs reviews, so the conflict sits with one person	Role assignments in the ISMS, a second approver for privileged changes, logs showing who reviewed what, and a documented reason the overlap is acceptable	Low cost in headcount but steady review time from the founder. Departure leaves no owner, so name a deputy and keep access records current
Fractional or part-time security lead runs the ISMS, founders approve policy	The lead owns ISMS operation, while founders keep approval rights, which separates running controls from approving them	Appointment of the lead in writing, scope of authority, records of management review chaired by top management, and evidence the lead has the competence for the role	Recurring fees and scheduled reviews, depending on the agreed scope. Confirm in the written agreement what happens to records if the engagement ends
Outsourced IT or hosting provider runs technical controls	The provider operates infrastructure, logging and backups, while the company keeps ownership of decisions and approvals	Supplier review under the supplier controls, contracts with security terms, the provider's own assurance documents, and proof the company reviews provider access and logs	Recurring supplier reviews and oversight time. Confirm how the provider's administrators are reviewed and how exit terms return data and evidence
Dedicated security hire once headcount justifies it	The hire holds the ISMS and security operations role, which reduces overlap but adds a second-line reviewer question for the founders	Job description with assigned responsibilities, onboarding and competence records, segregation between administrators and approvers, and internal audit results	Largest recurring cost of the four options. Departure still needs a handover plan, so keep runbooks and credentials documented outside any one person

How to evidence competence for each role under clause 7.2

This sequence turns the people who run or touch the ISMS into a documented role register, a set of competence records and awareness evidence that an auditor can sample. It works the same whether an outside consultant helps with implementation or the company does the work itself.

List every role that affects information security
Start with a register of the roles that touch the ISMS, including founders, the engineer who holds production access, the person who approves payments, the operations lead and any contractor with system rights. In a small company one person often appears several times, so list each role separately and name the person holding it. Management owns this list under clause 5 because it sets the responsibilities that A.5.2 asks for. The step is complete when every person with a security-relevant duty appears on the register with at least one role and an accountable owner.
Define the competence each role needs
For each role on the register, write down the knowledge and skills the work requires, such as handling access reviews, running backups, reviewing logs or responding to an incident. Clause 7.2 asks the organization to determine the necessary competence and make sure people are competent on the basis of education, training or experience. Keep the definitions short and tied to tasks the person actually performs. The output is a competence matrix that maps each role to its required competencies, reviewed by top management before anyone is assessed against it.
Record how each person meets the requirement
Assess each person against the matrix and record the evidence that supports their competence. Evidence can be a formal training course or certification, relevant prior experience, or supervised on-the-job work signed off by a more senior person. Note the date, the method and who verified it. For a small team, a short written assessment or a documented walk-through of a task is often enough, provided it is consistent across people. The output is a competence record per person that an auditor can trace from the role register to the evidence.
Close gaps with a documented action
Where the record shows a gap, decide and document an action: training, pairing with a competent colleague, reassigning the task, or recruiting. Record what was done and whether it worked by re-checking the competence record after the action. Where a single person cannot be competent in a role, the gap may need to go into the risk assessment or be covered by a second person, which links back to the segregation of duties work under A.5.3. The output is an action log that shows the organization noticed the gap and responded to it.
Run awareness for everyone, including the founders
Clauses 7.2 and 7.3 apply whoever does the implementation work, so the people who wrote the ISMS still need to be competent and aware. Provide security awareness content to all personnel and relevant contractors covering the policies they must follow, how to report a security event and their role in the controls that apply to them. Record attendance or acknowledgement with dates. The output is an awareness record for each person that matches the roster on the role register.
Keep the records as documented information
Store the role register, competence matrix, competence records, training completion and awareness records as documented information under clause 7.5. Set a clear owner, a version, a retention approach and access controls so the records are current and protected. Confirm that the records are consistent with the Statement of Applicability and the access rights in use. The output is a controlled set of records that an internal audit or certification body can sample without asking the team to reconstruct them.
Review the records when roles change
Update the role register and competence records whenever someone joins, changes responsibilities or leaves, and when a control or tool changes what a role needs. Confirm that leavers' access is removed and that new starters complete their awareness before they receive production access. Review the set at the internal audit and management review points that clause 9 requires. The output is a dated history showing the register and records track the real organization, which is the evidence that the competence process works rather than existing only on paper.

Evidence that shows roles are working, not only written down

A small team can write down every role and still fail an ISO 27001 audit if the records do not show the roles operating. The cards below cover the records an assessor typically samples to test clause 5 leadership, A.5.2 and A.5.3 segregation, clause 7 support, and the communication that ties them together. Each card names what to check before the audit and who must sign off.

Signed role and responsibility record

This is the register that maps each information security role to a named person, with the duties, decision rights and backup for each role. It answers A.5.2 directly, and an assessor will compare it against org charts, job descriptions and the access register to see whether the same people appear everywhere. Before the audit, confirm every named owner still works in that role and that a deputy is named for each one. The CEO or top management representative must sign off, because clause 5.3 makes top management responsible for assigning these responsibilities.

Policy approval and management review minutes

Approved policies with version numbers, approval dates and approver names show that leadership owns the ISMS, which is what clause 5.1 and 5.2 test. Dated management review minutes should record the inputs reviewed, decisions taken and actions assigned with owners and due dates. Check that actions from the previous review were closed or carried forward, since assessors often sample that link. Top management must sign the minutes and approve the policy, even when an outside consultant drafted both.

Privileged and conflicting access register

A register listing who holds administrator, production deployment, financial approval and security administration rights shows how A.5.3 segregation and A.8.2 privileged access are applied. In a small team one person often holds several conflicting rights, so the register should record each combination, the compensating control (such as a second approver or logged review) and the review date. Before the audit, export the live access list from each system and reconcile it with the register. The system owner and the security lead must sign off each conflicting combination.

Change approvals with a separate reviewer

Change records for production code, infrastructure and configuration show whether A.8.32 change management works in practice. Where the author cannot also approve, the record should name a different reviewer, and the approval should exist before deployment. A sample of recent changes will show whether approvals were given in the tool or after the fact. If the team is too small for two people on every change, the record should state the exception and the review that compensates for it. The engineering lead must approve the exception rule and sign the sample review.

Competence and awareness records

Competence evidence under clause 7.2 and awareness under 7.3 shows that people in each role can perform it. For a small team this can be a short record per role listing the qualification, training, supervised experience or certificate relied on, plus dated awareness completions for all staff. Check that records exist for contractors and founders too, since assessors do not exempt them. HR or the people lead must hold the training records, and each role owner must confirm competence for their own role.

Communication record for who is told what

Clause 7.4 expects the organization to decide what is communicated, when, to whom and by whom. A communication plan or matrix covering customers, staff, suppliers, the certification body and regulators, with dated examples of incident or change notices, shows the decision was applied. Before the audit, pick two or three recent messages and confirm the sender held the role the plan assigns. The role owner responsible for communications must sign off the matrix, and the top management representative should confirm it matches the roles register.

Who does what: the company, an implementation partner and the certification body

The organization owns the information security management system (ISMS) and every decision inside it. Top management must show leadership under clause 5, which covers leadership and commitment, the information security policy, and organizational roles, responsibilities and authorities. Those duties stay with the company even when an outside firm helps build the system, because the certification auditor will test whether leaders actually run it.

Policy approval: Senior leaders approve the information security policy and the scope of the ISMS, and they can show that they reviewed it.
Role assignment: The company names an owner for each role under A.5.2 and records who holds which responsibility, including people who hold several roles.
Control operation: Staff perform the controls day to day, such as access reviews, onboarding checks and incident handling.
Evidence retention: The company keeps the records that show each control ran, such as review sign-offs, tickets and logs.
Management review: Leaders review ISMS performance and decide on resources and improvements.

Before signing any engagement, confirm in writing which of these tasks the company will perform itself and who on the staff holds each role.

What usually breaks roles and segregation in a small ISMS

Small teams rarely lack good intentions on information security. The problems tend to be structural: leaders who stay out of the ISMS, one person holding every key, and roles that were never written down or revisited. Each card below names one failure, the fix an assessor will expect to see, and the record that proves the fix is working.

Top management delegates everything

Clause 5 expects top management to show leadership and commitment, set the information security policy and assign roles. In a small company the founder often hands the whole ISMS to one staff member or a consultant and never appears in its records. Fix this by having leadership review the ISMS on a fixed schedule, approve the policy and the risk treatment decisions, and attend the management review. The proof is signed minutes that show what leadership read, decided and resourced.

One founder holds every role

When a single person administers systems, approves access, changes code and then audits the same work, A.5.3 is not met. Segregation of duties is about reducing the risk of fraud, error and bypassed controls, so the question is whether one person can make and hide a change. Where people cannot be separated, document the compensating control, such as a second reviewer for production changes or a periodic review by someone outside the role. The proof is a role matrix plus approval records showing a different person reviewed the work.

Roles written once and never reviewed

Many small ISMSs define roles in the first policy pack and then let them drift. A hire takes over a system, a contractor leaves, or a founder adds a title, and the document still names the old owner. Set a trigger for review on every hire, departure and role change, and review the roles list at least at each management review. The proof is a dated roles and responsibilities document with a change history that matches the staff movements in the HR records.

Competence assumed, not recorded

Clause 7.2 asks the organization to determine the competence needed for each role, make sure people have it, and keep evidence. Small teams often believe experience is enough and have nothing on file. For each security role, list the required knowledge or training, record how it was met, and note the date. The proof is a competence record per role, such as training completion, certifications held, or a documented on-the-job review signed by the manager.

Access register out of date

Access control evidence depends on knowing who holds which rights. Under A.5.18 and A.8.2, the access register should show each account, its owner, its privileges and when it was last reviewed. Small teams often keep admin rights from a former project or a shared login nobody can name. Run a documented access review against the register, remove stale accounts, and record the reviewer. The proof is a dated review with the accounts removed or confirmed, signed by someone other than the account holder.

Ownership decided during the audit

When the certification body arrives and the team starts asking who owns the backup process, the answer is often improvised. Ownership should be settled before the stage 1 audit so each control in the Statement of Applicability has a named owner and a backup owner for absences. Confirm this with a short walkthrough where each owner explains their evidence. The proof is an owner column in the Statement of Applicability and records showing each owner has run their control at least once before the audit.

How far a scaled ISMS can go before a small team needs more people

ISO/IEC 27001:2022 expects the implementation to be scaled to the needs of the organization and integrated with its overall management structure, so a small company can keep lightweight, proportionate records instead of a large document set. A five-person team can often run one short policy set, a single risk register and a meeting-based management review. What it cannot do is skip requirements. The clauses on context, leadership, planning, support, operation, performance evaluation and improvement apply in full, and every control in the Statement of Applicability that the organization claims as applicable needs a named owner and evidence that it operates. Scaling changes how much paperwork sits behind each requirement, not whether the requirement exists.

Headcount also drives the certification body's audit effort. Under clause C.3.4 of ISO/IEC 27006-1:2024, as explained in European Accreditation FAQ 48.6, a certification body may reduce the head count of each group of people performing identical activities according to the risk of their tasks. The reduction cannot go below the square root of that group's head count, and the certification body must justify and document its criteria. For a small team, this means the sampling and audit days may be lower than for a large group, but the floor still applies to each group. A practical step is to list your staff by the activities they perform, so you can see which groups the auditor is likely to treat as identical.

Ask your certification body, in writing before you sign, how it applies this reduction to your organization, which groups it treats as identical, what risk criteria it uses, and how the resulting audit days are calculated. Compare its answer with the scope of your roles and your planned headcount growth, since hiring during the cycle can change the calculation. Confirm these points directly with the certification body rather than relying on general guidance, because the criteria are its own and must be documented.

Questions small teams ask about ISO 27001 roles and segregation

Can a founder be the information security manager under ISO 27001?

Yes, a founder can hold the information security role if the role is defined, documented and given real authority. Control A.5.2 asks the organization to define and allocate information security roles according to its needs, and it does not require a separate person with a particular job title. The risk for a founder is concentration: if the same person sets policy, approves access, grants exceptions and reviews their own decisions, the arrangement conflicts with A.5.3 on segregation of duties. Small teams usually document a named deputy or an independent reviewer for those decisions and keep the approvals in writing. Confirm with your certification body how it will test the arrangement and whether it expects specific compensating records.

Do we need a separate person to approve production changes?

A separate person is not always required, but the person who builds a change should not be the only person who approves and deploys it. Control A.5.3 asks that conflicting duties be segregated to reduce the risk of fraud, error and bypassing controls, and control A.8.32 covers change management. Small teams commonly meet this with a second reviewer on each change, a peer approval recorded in the version control system, or a logged review after an emergency change. Describe the chosen method in your change procedure and in the Statement of Applicability so the auditor can trace it. Confirm with the certification body that the compensating method meets its expectations before you rely on it.

What does an auditor check for top management involvement?

The auditor checks that top management leads the ISMS in practice, not only on paper. Clause 5 covers leadership and commitment (5.1), the information security policy (5.2) and organizational roles, responsibilities and authorities (5.3), and an auditor will test each one. Typical evidence includes a signed policy, minutes showing management reviewed information security and allocated resources, and records of decisions on risk and objectives. The auditor usually interviews the people named in the roles register to confirm they understand their duties. A consultant can help draft these records, but the leaders must take the decisions and be able to explain them during the audit.

How much effort do roles and competence records take each month?

Most of the effort is recurring and small, but it grows with headcount, staff turnover and the number of systems with privileged access. Clause 7.2 requires the organization to determine the competence needed for people doing security-relevant work and to keep evidence of it, and clause 7.5 covers the documented information that proves this. In a small company, monthly work typically means updating the roles register after joiners, movers and leavers, checking privileged access lists, and filing training or briefing records. The effort is not set by the standard, so ask your implementation partner and certification body to describe the recurring tasks in writing before you agree a plan. Tooling that records approvals automatically can reduce the manual load.

Can an implementation partner write our role register for us?

An implementation partner can draft the role register, but your organization must approve it, own it and keep it current. DeployOpen prepares systems, controls and evidence for assessments, while the organization owns its controls and an independent certification body issues any certificate. Your leadership must decide who holds each role, sign the authority granted, communicate it to staff and confirm that people accept their duties. Keep in mind that the certification body must stay independent of the consultant, so check the conflict of interest guidance in European Accreditation FAQ 49.4 and the consultancy guidance in FAQ 33.15 before you engage anyone.

Does the certification body count our people differently for audit time?

It may, because the certification body can reduce the counted head count for groups of people doing identical activities, according to the risk of their tasks. Clause C.3.4 of ISO/IEC 27006-1:2024 sets a floor: the reduced count cannot fall below the square root of the group's head count, and the certification body must justify and document its criteria. As an illustrative example only, a group of 16 people performing identical tasks could not be counted below 4 under that rule. Ask the certification body for its written criteria, how it groups your staff and how it treats remote or contractor staff, because these choices drive audit days and cost. The European Accreditation FAQ 48.6 explains the method in more detail.

How DeployOpen helps a small team set up roles, segregation and evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the systems that carry your ISO 27001 roles, access rights and competence records are set up to match how a small team actually works. We prepare systems and evidence for your assessment; your organization owns its controls and your independent certification body issues any certificate.

How we scope

We agree a written scope listing which roles, access paths and competence records the engagement covers before work starts.
We map who holds each responsibility today, including people who hold several roles, so conflicts are visible before anything is changed.
We confirm with you which decisions stay with top management and which tasks may be delegated, and record that split in the scope.

How we build

We configure role-based access and privileged access in your self-hosted tools so that approvals and administration are separated where your team size allows.
We set up approval workflows and change records so that one person cannot both request and approve a change without a second check.
We build competence and awareness records, such as training logs and role descriptions, in systems your team already uses.

How we hand over

We document the role assignments, segregation decisions and compensating reviews in a form your certification body can sample.
We walk your team through the access reviews and evidence exports so that they can repeat them after the engagement ends.
We deliver a written handover covering owners, review frequency and where each piece of evidence is stored.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the handover, if your team wants help between audits.
We can review role changes, new hires and access reviews on a retainer basis, using the same records built during the engagement.
Before any retainer starts, confirm in writing which reviews the retainer covers and who in your organization signs off each one.