I started working as an ISO 27001 lead auditor in 2015. That gave me a close view of how organizations were implementing the standard, where they struggled, what consultants were building for them, and how auditors assessed the resulting management systems.
Two years later, we launched Instant 27001. At the time, our proposition was relatively unusual: a growing technology company should not have to design an entire information security management system from scratch. Many of these organizations face similar risks, use similar technologies, operate similar processes and, ultimately, need to meet the same requirements.
That did not mean every organization was identical, nor that ISO 27001 could simply be reduced to a set of standard documents. It meant that a large part of the underlying management system could be prepared in advance, leaving organizations to focus their time and attention on the areas that genuinely required judgment, ownership and adaptation.
Nearly 3,000 organizations later, that idea feels considerably less radical. In fact, if you look at the compliance market today, almost everyone seems to agree that ISO 27001 should be faster to implement, easier to understand, less dependent on consultants and less burdened by paperwork that adds little practical value.
What was still a fairly unconventional proposition in 2017 has become a mainstream message across the compliance industry. I think that is progress, but the way the market has evolved raises another question: in our effort to make ISO 27001 simpler, have we sometimes started confusing simplification with automation?
Ten years ago, ISO 27001 implementations were still commonly approached as highly bespoke consulting projects. The assumption was often that every organization was fundamentally unique and that, as a consequence, every ISMS needed to be designed from the ground up.
Policies were written from scratch, procedures were written from scratch and risk methodologies were invented from scratch. Consultants spent significant amounts of time interviewing people before producing large collections of documents, many of which were difficult for the organization itself to maintain once the implementation project was over.
Some customization is obviously necessary. Every organization has its own context, customers, legal obligations, technology, risk appetite and way of working, and a good ISMS needs to reflect those realities. However, uniqueness has limits.
A 60-person SaaS company does not need an entirely new interpretation of access control simply because its product is different from that of another SaaS company. It still needs to manage access, suppliers, incidents, changes, assets, risks and responsibilities. It still needs management reviews, internal audits and continual improvement. The details will differ, but the basic structure of the management system often does not.
That was one of the fundamental ideas behind Instant 27001 from the beginning: standardize what can reasonably be standardized, and spend time on the parts that actually require thought. Over the past decade, the market has increasingly moved in the same direction. The idea that an ISMS can be pre-built to a significant extent is no longer particularly controversial, especially for technology-driven organizations with comparable operating models and risk patterns.
Then software took that idea one step further.
The rise of compliance automation platforms was a logical development. If ISO 27001 implementations involve repetitive administrative work, it makes sense to use software to reduce that burden.
There is plenty that software can do well. It can collect information, send reminders, monitor configurations, check whether certain settings are enabled, and help organizations track tasks, evidence and control status. Used appropriately, automation can remove a meaningful amount of manual work from maintaining an ISMS.
The difficulty begins when simplifying ISO 27001 becomes synonymous with automating ISO 27001, because those are not the same thing.
ISO 27001 is not fundamentally a data collection framework. It is a management system, and management systems are largely about people making decisions. Organizations still need to determine who owns a risk, whether that risk is acceptable, whether additional controls are necessary, whether a supplier remains appropriate, what was learned from an incident, and why a process did not work as intended.
The same applies to the operation of controls. Collecting evidence that a particular setting is enabled is useful, but it does not tell you whether access rights are being managed intelligently. Recording that a supplier review took place does not tell you whether the organization properly understood the risk represented by that supplier. Scheduling a management review does not mean that management genuinely understands the issues being discussed.
Software can support all of those activities, but it cannot replace the judgment behind them. This distinction matters because an ISMS is not supposed to produce evidence for its own sake. Evidence is useful because it helps demonstrate that the organization is actually doing what it claims to be doing. Once the evidence itself becomes the objective, it becomes very easy to confuse compliance activity with effective information security management.
Good auditors tend to recognize that distinction quickly. An organization that can clearly explain why it made certain decisions, how it manages its risks and how its ISMS works is usually in a much stronger position than one that can present hundreds of automatically collected data points but struggles to explain what those data points actually mean.
Automating evidence is not the same as operating a management system.
There is another aspect of compliance automation that deserves more attention, particularly because it concerns information security itself.
Many automation platforms create value by integrating deeply with the systems they monitor. Depending on the platform, that can mean connections to Microsoft 365, Google Workspace, AWS, Azure, identity platforms, source code repositories, HR systems, endpoint management tools and other critical services.
Those integrations can be genuinely useful. They can save time, provide visibility and remove tedious manual checks. The question is not whether integrations are good or bad. The question is whether organizations apply the same level of risk thinking to their compliance tooling that they would apply to any other critical supplier.
A platform that connects to several of your most important cloud systems becomes part of your security architecture, whether you think of it that way or not. That makes questions about permissions, data access, dependency and attack surface relevant. Organizations should understand how much access the platform needs, what information it can retrieve, how many critical systems are connected through a single supplier, and what the impact could be if that supplier, one of its integrations or one of its privileged accounts were compromised.
These are not arguments against compliance automation platforms. In many cases, the trade-off will be perfectly reasonable. But it is still a trade-off, and ISO 27001 is precisely the kind of management system that should encourage organizations to think consciously about such trade-offs.
There is a certain irony in strengthening the evidence of your security posture by giving another third party elevated access to the systems you are trying to protect. Sometimes that is the right decision, but it should be a decision rather than a default.
I do not believe the future of ISO 27001 is manual, and I certainly do not believe organizations should return to the consulting-heavy implementations of a decade ago. A mature approach sits somewhere between those extremes.
There is little value in repeatedly reinventing things that have already been solved well. Standardization can remove enormous amounts of unnecessary work, particularly when organizations share the same fundamental risks and requirements. Automation can do the same for genuinely repetitive activities.
But some parts of an ISMS are valuable precisely because they require people to think. Risk management should involve judgment, management reviews should involve management, and internal audits should challenge the organization rather than merely confirm that evidence exists. Incidents should result in learning, supplier decisions should reflect business context as well as technical data, and policies should describe how people are actually expected to work rather than simply satisfying the existence of a control.
That is not an argument for complexity. In fact, I think unnecessary complexity remains one of the biggest obstacles to an effective ISMS.
Complexity does not demonstrate maturity, and neither does document volume. A long policy is not necessarily better than a short one, and a highly customized management system is not automatically more sophisticated than a standardized one. The same caution should apply to automation: a dashboard full of green indicators can be useful, but it is not a substitute for organizational understanding and ownership.
The more mature question is therefore not how much ISO 27001 can be automated, but which parts should be standardized, which parts should be automated and which parts remain more effective when people stay directly involved.
It would be difficult to write about the evolution of the ISO 27001 market without also acknowledging how much Instant 27001 itself has changed during the same period. The Instant 27001 of 2026 is a very different product from the one we launched in 2017.
The original idea is still recognizable. We continue to believe that organizations should not need to reinvent an ISMS from scratch, that unnecessary complexity should be removed, and that a management system should be practical enough for the organization itself to understand and operate. But almost everything around that idea has developed.
ISO 27001 itself has changed, audit practices have evolved, technology environments have changed considerably, organizations have become more security-aware, and new regulations have appeared. At the same time, customers increasingly want to combine ISO 27001 with additional standards, frameworks and sector-specific requirements. Instant 27001 has evolved alongside those changes.
What began primarily from my own experience as a lead auditor is now informed by nearly a decade of real implementations. Over the years, the number of customers, consultants, partners and auditors we interact with has grown enormously, giving us continuous exposure to how the standard is interpreted and implemented across different organizations and markets.
That feedback matters because a pre-built ISMS cannot afford to become theoretical. Its value depends on how closely it reflects the reality of implementation and audit.
We have also expanded beyond the original Confluence product. Instant 27001 is now available for Microsoft 365 and Notion, and the system can be extended to support a growing range of additional standards and frameworks.
None of that means that every customer environment changes automatically as Instant 27001 evolves. It means that the product we offer today reflects what we have learned since 2017. The assumptions have been tested, the content has been revised, and the way the system is delivered has changed with the market around it. In that sense, the product has matured in much the same way as the market itself.
When we launched Instant 27001, one of the ideas behind it was that ISO 27001 did not need to be as difficult as the market often made it. Today, that idea is hardly controversial, and I am quite happy about that.
The compliance industry has made ISO 27001 more accessible. Software has removed real administrative burdens, and organizations that might once have postponed certification because the process looked too complicated now have many more ways to get started. That is a better market than the one we entered in 2017.
But as the market continues to mature, I think the distinction between simplification and automation becomes increasingly important. Removing unnecessary work is useful, removing unnecessary complexity is useful, and standardizing what does not need to be reinvented is useful. Removing people from decisions that fundamentally depend on ownership, judgment and understanding is something else.
ISO 27001 is ultimately about taking control of information security. The tools, templates, integrations and evidence should support that objective, not become the objective themselves.
Almost ten years after launching Instant 27001, that principle feels just as relevant as it did when we started.
See Instant 27001 in action and learn how we can help you kickstart your ISO 27001 project.
Devi effettuare l'accesso per postare un commento.