All articlesISO 27001

ISO 27001 consultant or compliance platform?

ISO 27001 consultant or compliance platform?

In short

  • Consultants are strongest on scope, risk assessment and decisions that need judgement.
  • Platforms are strongest on evidence collection and keeping controls visible between audits.
  • Templates and integrations show configuration, not whether a process actually works.
  • Neither model operates monitoring, incident response or vulnerability management.
  • Ask every provider who owns each decision after the first certificate.

Should I use an ISO 27001 consultant or a compliance platform?

An ISO 27001 consultant brings judgement on scope, risk and documentation but usually works as a project with an end date. A compliance platform brings continuity, collecting evidence and tracking controls over time, but cannot make decisions for you. Neither operates security controls such as monitoring or incident response, which the certificate still depends on.

What an ISO 27001 consultant delivers

A consultant brings judgement to the parts of ISO 27001 that cannot be templated. The typical engagement covers a gap analysis against the standard, defining the scope of the information security management system (ISMS), designing the risk assessment methodology and running the first assessment, writing the policies and the Statement of Applicability, and preparing the organisation for the certification audit.

The value is in decisions. What sits inside the scope and what stays out. Which risks are acceptable. Why a given Annex A control applies or does not. These are the questions an auditor probes in Stage 1, and an experienced consultant has seen how auditors react to the answers.

How a typical engagement runs

Most consultancy projects follow a similar arc. They start with interviews and a gap analysis that compares current practice with the clauses and Annex A controls. Then come the foundation documents: the scope statement, the information security policy and the risk methodology. The risk assessment follows, usually run in workshops with the consultant facilitating and the business supplying the knowledge. From the risk treatment decisions comes the Statement of Applicability, then the remaining policies and procedures. The project usually ends with an internal audit, a management review and support during the certification audit.

A good consultant transfers ownership as the project runs: the people who will operate each process write or at least rewrite the procedures that describe it, and the risk owners make and record the treatment decisions themselves. A weaker engagement produces a complete document set that the organisation reads for the first time a week before Stage 1.

Signs of a strong consultancy

Consultancies vary widely, and the differences show up early. Useful signals include a gap analysis that refers to specific clauses and controls rather than general maturity scores; a risk methodology explained in a page, not a spreadsheet nobody else can read; consultants who have prepared organisations for audits with certification bodies accredited under ISO 27006-1; and a clear plan for how documents will be handed over and who will maintain them. A proposal that promises a complete document set in a fixed number of days, without asking how the company works, is usually a sign that templates are doing most of the work.

Where the consultancy model reaches its limits

The limits come from the format. A consultancy engagement is usually a project with a start and an end. When it ends, three things tend to happen:

  • The documents were written by someone outside the company, and the people who must follow them do not always recognise their own processes in them.
  • Evidence collection is manual and lives in shared folders, so nobody notices a lapsed control until the surveillance audit approaches.
  • The knowledge of why each decision was taken leaves with the consultant.

There is also a structural issue with the internal audit. ISO 27001 clause 9.2.2 requires internal auditors to be selected so that the audit is objective and impartial. A consultant who designed the ISMS is poorly placed to audit it. Some consultancies solve this by assigning a different consultant to the internal audit, which helps, but it is worth asking explicitly.

What a compliance platform delivers

A compliance platform is software that structures the ISMS as a set of controls, tasks and evidence. Typical capabilities include a control library mapped to Annex A, policy templates, integrations with cloud, identity and HR systems that collect evidence automatically, task assignment and reminders, and mapping of the same controls to other frameworks such as ENS or SOC 2.

The value is continuity. Controls stay visible between audits. A lapsed access review or an unencrypted laptop shows up on a dashboard instead of in an auditor's finding. Evidence is time stamped and traceable, which is what surveillance audits sample. How that works in practice is covered in how a compliance platform collects and traces audit evidence.

What automation covers well

Integrations are strongest where evidence is a configuration or a list that a system already holds:

  • Whether multifactor authentication is enforced in the identity provider.
  • Whether laptops are encrypted and have endpoint protection installed.
  • Whether cloud storage is private and logging is switched on.
  • Which employees joined and left, and whether their accounts were created and removed.
  • Whether staff have acknowledged policies and completed training.

For these, a platform turns a manual collection exercise into a continuous check. Mapping the same evidence to several frameworks also avoids collecting it twice when ISO 27001 sits alongside ENS or SOC 2.

What to check when choosing a platform

Platforms differ less in their control libraries than in how well they fit the systems a company actually uses. Before choosing, check which of your identity, cloud, endpoint and HR tools it integrates with, and what evidence each integration produces. Ask how evidence for controls without an integration is collected and reviewed. Check whether policies can be rewritten freely or only lightly edited, and whether the platform supports the other frameworks you expect to need, such as ENS for Spanish public sector work. Finally, ask who on the provider's side answers questions about the standard itself, as opposed to questions about the software.

What automation cannot decide

The limits come from the same source. A platform can hold a risk register; it cannot decide which risks your business accepts. It can generate a policy from a template; it cannot know whether that policy describes how your teams actually work. And integrations confirm configuration, for example that multifactor authentication is enforced, not that a process such as incident handling or supplier review is carried out well.

Template policies carry a specific risk in an audit. An auditor reads the policy, then interviews the people it applies to. If the policy describes a change approval board the company has never held, the gap becomes a finding, and the auditor starts to wonder what else in the documentation is aspirational.

Platforms bought without anyone to run them follow a familiar pattern: the dashboard fills with red items, nobody owns them, and the project stalls. That pattern is covered in how to restart a stalled ISO 27001 project.

Where each one leaves gaps

Put side by side, the two models fail in opposite directions. The consultant provides judgement without continuity. The platform provides continuity without judgement.

Following the work through the certification cycle shows where each gap appears:

  • Scope and risk assessment. Strong with a consultant. A platform offers structure and a register but no judgement on what belongs in scope or which risks matter.
  • Policies and the Statement of Applicability. A consultant tailors them; a platform provides templates. In both cases, someone inside has to confirm they describe reality.
  • Evidence collection. Manual with a consultant, usually in folders. Automated for configurations with a platform, manual for everything else.
  • Internal audit. A consultant can run it if impartiality is managed. A platform can hold the checklist but does not audit.
  • Surveillance audits in years two and three. Often not covered by the original consultancy project. A platform keeps the evidence flowing, if someone keeps acting on it.

Which model fits which situation

The right mix depends on where the organisation starts. A company facing its first certification under a customer deadline, with no one internally who knows the standard, needs judgement first: scope and risk decisions taken well at the start save months later. A company that already holds a certificate but struggles to keep evidence current between audits needs continuity more than new documents. A company running several frameworks at once, such as ISO 27001 and ENS, benefits most from mapping evidence across them. And a company with no internal IT security capacity at all needs, before either of these, someone to operate the controls the certificate describes.

Both share one gap that the standard does not allow anyone to outsource completely: ownership. ISO 27001 clause 5.3 requires top management to assign responsibilities and authorities for the ISMS, and clause 9.3 requires top management to review it. A consultant can draft the management review agenda and a platform can produce the report, but the decisions recorded in it belong to the organisation.

In practice, the question is not consultant or platform. It is who inside the company owns the ISMS, and what support that person needs to keep it running after the first certificate.

What neither one covers

Neither model operates security. ISO 27001 Annex A includes controls that only exist if someone runs them day to day:

  • Monitoring activities (control 8.16): networks, systems and applications monitored for anomalous behaviour.
  • Incident management (controls 5.24 to 5.26): events assessed, incidents responded to and lessons recorded.
  • Management of technical vulnerabilities (control 8.8): vulnerabilities identified, evaluated and remediated.
  • Awareness, education and training (control 6.3): delivered and measured, not just scheduled.

These controls generate the records that surveillance audits return to every year, because they are where a management system meets daily operations. A consultant can write the incident response procedure. A platform can track whether the vulnerability scan ran. Neither triages an alert at three in the morning or patches a server. If those controls are applicable in the Statement of Applicability, the organisation needs someone to operate them, and surveillance audits will sample the records they produce.

Several other controls sit in the same position, even if they look administrative: access reviews (5.18) need someone to decide whether each permission is still justified; supplier assessments (5.19 to 5.22) need someone to read the answers and act on them; continuity tests (5.30) need someone to run the exercise and record what failed. Software can schedule and track all of them. People have to do them.

What that looks like in an audit

Consider control 8.16. The policy says security events are monitored. The auditor asks to see the alerts from last month and what happened to each one. An organisation with no one watching the alerts has two answers available: there were none, which is rarely credible, or there were some and nobody looked. Either way the control is not operating, and the policy that describes it has become a liability.

The same applies to vulnerability management. A scanner that runs every week produces reports. The control is the remediation that follows, with dates, and the decision to accept the risk where a fix is not possible. The difference between documenting a control and running it is the subject of compliance platform vs security: what a licence misses.

Questions to ask any provider

Whichever model you consider, these questions separate a certificate that holds from one that fades after year one. For each, the useful part is less the yes or no than how specific the answer is.

  • Who carries out the risk assessment, and who in our company signs off the risk treatment decisions? A good answer names a method and describes workshops with your risk owners, not a register prefilled from a library.
  • Who maintains the Statement of Applicability when the business changes? A new product, a new office or a new cloud provider changes the scope and the risks. Someone has to notice and update the documents.
  • Who runs the internal audit, and how is its impartiality ensured? Listen for how the auditor is kept independent from whoever built and runs the ISMS.
  • How is evidence collected for surveillance audits in years two and three? If the answer is "we will prepare you before each audit", expect a scramble every year.
  • Which Annex A controls do you operate, and which do we have to operate ourselves? Ask for a list against the Statement of Applicability, not a general description.
  • What happens when an alert fires outside working hours? If nobody is named, monitoring is a report someone reads in the morning.
  • What does the first year after certification look like, month by month? A provider who has done this before can describe the recurring controls, the internal audit, the management review and the surveillance audit as a calendar, with an owner for each item.
  • Who will be in the room during the certification audit? Auditors interview the people who run the processes. A provider can prepare them and support during the audit, but cannot answer on their behalf.
  • What do we keep if we stop working with you? Documents, evidence history and configurations should remain the organisation's, in formats it can use.

The answers show where the work will fall once the provider is no longer the centre of attention. If the honest answer to most of them is "your team", the next question is whether your team has the time and the skills.

Combining the two models

Many organisations end up combining a consultant for the initial decisions with a platform for continuity. It can work, but the handover between them is where things get lost: the consultant's rationale for scope and risk decisions rarely makes it into the platform, and the platform's alerts have no one with the authority to act on them. If you combine them, agree in advance who owns the ISMS once the consultant leaves, and who operates the controls neither of them covers.

A platform with guided support

Qalea combines a compliance platform with guided support from a security team, so the continuity of software and the judgement of people sit in the same service. The platform maps controls to ISO 27001 and other frameworks and collects evidence continuously. Our team works with yours on scope, risk assessment, the Statement of Applicability, internal audit and management review, with a virtual CISO where the role is needed.

Qalea also operates the controls neither a consultant nor a platform covers: EDR on endpoints, SIEM and a 24/7 SOC for monitoring and incident response, and attack surface and vulnerability management. The organisation keeps ownership of the ISMS and its decisions. What it no longer has to do alone is run the security function the certificate depends on.

Frequently asked questions

Can a compliance platform replace an ISO 27001 consultant?

Not entirely. A compliance platform tracks controls and collects evidence continuously, but decisions on scope, risk acceptance and control applicability still need someone with ISO 27001 experience. Many organisations pair a platform with guided support for those decisions.

Can the consultant who built our ISMS also do the internal audit?

It is a weak arrangement. ISO 27001 clause 9.2.2 requires internal auditors to be chosen so the audit is objective and impartial. Someone who designed the ISMS would be auditing their own work, which an external auditor is likely to question.

Does a compliance platform make a company ISO 27001 compliant?

No. A compliance platform structures controls and evidence, but compliance depends on the organisation deciding its scope and risks and operating its controls. Integrations confirm configuration settings, not that processes such as incident handling or supplier review are carried out.

Which ISO 27001 controls require daily security operations?

Controls such as monitoring activities (8.16), incident management (5.24 to 5.26) and management of technical vulnerabilities (8.8) only exist if someone operates them continuously. Surveillance audits sample the records these controls produce.

More articles

All articles