On many an SME's ISO 27001 project list, one line causes more discussion than all the rest: appoint a CISO. What follows underneath, documents, risk assessment, audits, looks harmless next to it.
The line reads like a hiring decision, which is why it tends to land with the management team along with the question of whether you now have to employ someone or buy someone in. That is the wrong first question. At this point the standard wants something else, and it is considerably less than the line suggests. The part it does care about, however, is harder to fill than a job.
Does ISO 27001 require a CISO?
No. The standard names no job title and no new box on the org chart. Clause 5.3 requires top management to assign responsibilities and authorities for the roles relevant to information security, and to make that assignment known within the organisation. Who does the work remains your decision.
This is also why a certification body does not check whether a CISO exists. It checks who is responsible for what, and how you can tell. That someone in an audit still asks about the CISO does happen, and what is meant then is the responsibility, not the title.
Whether the role is called CISO at your company, information security officer, or a paragraph in the managing director's job description, is of no interest to the standard. What gets checked is the assignment, not the name badge. For an SME the CISO title is often the most practical option anyway, because internally it makes clear at once that someone here is allowed to decide. A communication advantage, then, not a requirement of the standard.
What clause 5.3 actually requires
The standard gets specific on exactly two points. Top management assigns the authority, first for ensuring that the management system meets the requirements of the standard, and second for reporting on the performance of that system to top management.
In plain terms: one person has to be allowed to say that something is not running in conformity, and they have to get through with it as far as the management team. Not as far as the IT lead, not as far as the project meeting. As far as the place where money and priorities are decided.
It is worth separating two words that get mixed up in everyday use. Responsibility means doing the work and answering for its result. Authority means being allowed to decide. The standard wants both, and it wants them with the same role. An SME that appoints a CISO and gives them only the first has ticked the line on the project list and left the requirement open.
In Annex A the idea appears a second time, as control 5.2: information security roles and responsibilities are defined and allocated according to the needs of the organisation. Again no title, again the same two verbs. Define and allocate.
Two places in the same standard, both without a job description. That is no oversight. A standard meant to work for the fifteen-person firm and for the corporate group cannot prescribe an organisational form. What it prescribes is that the responsibility is assigned and that the reporting line exists.
This is exactly where it fails in SMEs, and not because of the title. It fails because the person doing the work does not have the second authority. The problem is seen, it is written down, and it stays stuck at the level where that person sits. Formally the role is filled. In practice the half that matters to the standard is missing.
How the assignment becomes visible
An assigned role that nobody knows about is not an assigned role. Clause 5.3 therefore covers both, the assigning and the making known. Clause 7.4 carries the thought further: you determine what you communicate about information security, when, with whom and by whom. In an SME this is not a communication strategy but usually a paragraph on the intranet and an item in onboarding.
The second piece of evidence is the reporting line itself, and it has a rhythm. Under clause 9.3, top management reviews the management system at planned intervals, with defined topics as inputs and with recorded results. Who compiles those inputs is left open by the standard. In practice it is the person from clause 5.3.
In our experience this is the most practical test for the whole question of the role, and it costs nothing. Look in the last minutes of your management meeting to see whether information security appears as its own item, and if so, who presented on it. If nobody is listed there, the second half of the role is missing, regardless of who holds the title.
The three decisions that need a name beforehand
Here lies the real reason to settle the question of the role early, and it has nothing to do with the audit. An ISO project calls for three decisions that can only be corrected expensively later. All three fall in the first weeks, often before anyone is formally responsible. A CISO who only joins once the project is running inherits them without having made them, and has to either defend them or reopen them.
The scope
Clause 4.3 requires the scope as documented information. What is inside gets audited. What is outside does not appear on the certificate, and that is what the customer who wants to see the certificate looks at.
In our experience this decision is rarely made by the person who has to carry it. It emerges in the project meeting, out of whatever looks feasible at the time. How to cut the boundary sensibly we worked through in the article on the ISO 27001 scope. The question here is a different one, namely who answers for that sentence in the end, even when a customer asks two years later why their site is not included.
Accepting the residual risks
For the risk treatment plan, clause 6.1.3 calls for the risk owners' approval and their acceptance of the residual risks. The standard itself uses the word owner here. How far you take that it leaves open; in our experience a risk only holds when a person stands behind it and not a department.
This is the most uncomfortable line in the whole project. An accepted residual risk is a decision with a name attached: we know this, we are leaving it, and this is the reason. Without a name it stays an open item on a list nobody reads any more.
Who is allowed to accept is not a matter of taste. It has to be someone who is also allowed to bear the consequences. An external CISO can supply the assessment and prepare the decision, but cannot accept it. What can be passed on from this responsibility and what cannot, we wrote down under outsourcing security responsibility.
Such an entry does not need much. The risk, the decision, the reason, the name and the date, plus a point in time when the matter comes back on the table. That fits into six columns, and in our experience it counts for more in an audit than a binder full of policies.
The exclusions in the statement of applicability
The statement of applicability from clause 6.1.3 records which Annex A controls you use and which you do not, with justification. Every exclusion is a claim about your operation, and exclusions are among the things asked about in the audit.
In our experience this is the point where projects quietly create work. When nobody with an overview decides, in case of doubt nothing gets excluded. Annex A of the 2022 version comprises 93 controls, spread across organisational, people, physical and technological. Anyone who leaves out none of those 93 with a justification feels on the safe side. In fact the system then carries controls that have to be described, implemented and evidenced every year, although they never concerned the business in question. That extra work is barely noticeable during the project. It becomes noticeable in the second and third year, when the system has to keep running without a project budget.
Who takes the role in an SME
Three ways of filling it work at this size, and none of them needs a new full-time position.
A member of the management team wears the CISO hat themselves. That resolves the authority immediately and cleanly, because both halves coincide anyway. It does take the time to get into risk assessment and evidence keeping, and in our experience that time is the point where it tips over. Not on understanding, but on the calendar.
The IT lead takes the role. In our experience this is the most common variant, and it works as long as the reporting line to the management team genuinely holds. The familiar blind spot remains: whoever is responsible for operations is, in case of doubt, judging their own work and reporting their own backlog. The difference between the CISO hat and the operations hat we took apart in CISO and information security officer.
Or the work and the judgement come from outside and the authority stays in house. That is our model: we bring the role as an external CISO, the management team keeps the decision, and the ISMS to ISO 27001 is built along those decisions rather than around them.
One limitation belongs with this, and the market likes to skip it. Clause 5.3 speaks of an assignment within the organisation. An external CISO may take on the work and the judgement, but the assigned responsibility still needs a name in house. Anyone who buys a mandate and thereby pushes the role off the table has in the end only outsourced who describes it.
Which of the three fits depends less on the budget than on a single quantity: how many hours per week the person you have in mind actually has free next month. Anyone who does not know that number should settle it before the project starts, not in the third month. For a second opinion on how you have filled the role, we are available for an initial conversation.
The difference the certificate does not show
Two businesses can have the same certificate on the wall. At one, behind every accepted risk and every exclusion stands a name, someone who decided it that way at the time and can explain why. At the other, the justifications came into being because the audit called for them. From the outside the difference is not visible, and in the audit mostly not either. It becomes visible two years later, when something changes and somebody wants to know why this was decided the way it was. It does not hang on whether anyone had CISO on their business card, but on whether that person was allowed to decide when it mattered.
If you look at your own risk register today: for how many entries does a person immediately come to mind who answers for that decision?
Frequently asked questions
Does ISO 27001 mandate a CISO?
No. The standard names no job title. Clause 5.3 requires top management to assign responsibilities and authorities for information security roles and to make that assignment known. This includes the authority to report on ISMS performance to top management. What the role is called is your decision.
Can an external CISO hold the clause 5.3 role?
Partly. An external mandate may take on the work and the professional judgement. Clause 5.3 speaks of an assignment within the organisation, however, so the assigned responsibility still needs a name in house. Only someone allowed to bear the consequences can accept a residual risk.
Which decisions need an owner before the ISO project starts?
Three. The scope under clause 4.3, the risk owners' acceptance of residual risks under clause 6.1.3, and the justified exclusions in the statement of applicability. All three fall in the first weeks and can only be corrected expensively later.
