Why ISO 27001 Auditors Can Reject Documentation

ISO 27001 is one of the most complex security frameworks commonly in use around the world. That complexity comes from the way it is designed: not as a checklist to follow, but rather as a series of guidelines to achieve.

The difference between those two things is stark, even if it doesn’t sound like it.

The way ISO 27001 works is that you develop an ISMS, or Information Security Management System. This is System in the more traditional sense; the sum total of tools, configurations, and processes that make up the environment in which you operate.

Before, we’ve likened it to more open-ended requirements. ISO 27001 doesn’t tell you to implement a specific encryption methodology; it tells you that sensitive data should be encrypted, and leaves it up to you to define what that means.

One of the challenges is that this lack of specificity applies to all parts of ISO 27001, including the documentation process. This often blindsides organizations seeking ISO 27001 approval when they present their documentation to auditors, only to have it rejected.

To avoid this rejection, it’s important to know what documentation you need, what documentation you don’t need, and how it should all be handled to avoid rejection from your auditors.

The Documentation Requirements for ISO 27001

First, what documentation is required?

ISO 27001 has documentation requirements laid out in clause 7.5.1. This clause defines what documentation is.

“The organization’s information security management system shall include:

1. Documented information required by this international standard; and

2. Documented information determined by the organization as being necessary for the effectiveness of the information security management system.”

Helpful, right? “Your ISMS needs documentation that is determined to be necessary for the ISMS.”

It’s no wonder that many organizations document every detail they can think of, and still fall short of the mark.

ISO/IEC has done some work through their secondary publications, like ISO 27002, to help explain their requirements.

“Information security policy and topic-specific policies should be defined, approved by management, published, communicated to and acknowledged by relevant personnel and relevant interested parties, and reviewed at planned intervals and if significant changes occur.”

Or

“The organization should plan and prepare for managing information security incidents by defining, establishing, and communicating information security incident management processes, roles, and responsibilities.”

Descriptions like this formalize the need to document different processes and procedures throughout your ISMS. Critically, though, they don’t tell you what that documentation looks like or how to compile it.

Where Organizations Fail

Many organizations take this to mean they should document every detail they can. That perspective is further reinforced by articles like this one that stress you should document everything, over and over.

The truth is both more difficult and a relief.

Think about it from the perspective of an auditor.

When they come to your business to audit your systems and your ISMS, they’re going to have a laundry list of security checks according to the ISO 27001 auditing procedure guides. They’ll check various elements of your ISMS, and along the way, they’ll be able to see firsthand the proof of various security controls and procedures.

The auditor doesn’t need a piece of paper telling them that you keep your doors locked when they check the door handle themselves, right?

Others can be documented in ways that are more convenient than developing your own unique documentation for them. A common example is when you manage various meetings and tasks through a centralized project management system. You don’t need unique documentation for ISMS meetings when the logs of the meetings in your project management system cover the same bases.

Or, you don’t need to develop documentation for your organization’s password complexity requirements, reset policies, and redundancy protection, if all of that is set in the configuration for your overall apps and is all located in something like Active Directory anyway.

Far too many organizations fail because they’re documenting everything and end up with piles of redundant documentation. Worse, if any of that documentation is contradictory, what would have been fine becomes a problem to sort out.

Why an Auditor Rejects Documentation

It’s also critical to think about your ISMS and your overall compliance from the eyes of the auditors for the purposes of documentation. Auditors can and will reject documentation if it doesn’t do what it says it does.

What are the major reasons why your documentation can be rejected?

Insufficient Documentation

One big example is insufficient documentation for relatively complex procedures and tasks.

Take risk assessment and management, for example. Risks are inherent in any organization, no matter how much security is in place. You need to have a procedure in place to identify risks, assess them across the risk evaluation axes, and how the risk is mitigated.

But that alone isn’t enough. You also need to identify how the risk can violate the confidentiality, integrity, or availability of information. You need to know who the owner of the risk is. You need to assess the likelihood of the risk. You need criteria for evaluating when a risk is acceptable versus when more can be done.

First-time organizations often approach this on more of a vibes-based set of criteria, and end up “documenting” things like “our managers use their judgement,” which really isn’t proof of anything at all.

ISO 27001 doesn’t stipulate that you need to use a specific set of criteria to judge risks. But they do require you to have a process, something objective and able to be replicated, which can be used to evaluate risks. It’s the difference between a pop quiz and a standardized test.

It’s very easy to fall short of the mark when the mark is fuzzy and distant, but it’s often easier to reach than most people think. It just requires giving it that extra thought to figure out what sufficient documentation would look like.

Lack of Ownership and Accountability

A big part of adequate documentation throughout a lot of ISO 27001 is accountability. You can have the best security policies in the world, but if anyone who breaks them or lets them slip thinks “well it’s not my problem” and passes the responsibility to someone else, and it never comes home to roost, then it’s not security at all; it’s theater.

Every procedure, every policy, every risk, every attribute, has an owner within your organization. The owner may be a role within a team, rather than a specific person, but there needs to be a defined place where someone, at some point, is the one whose responsibility is to ensure the policy is being implemented.

Hanging your auditor a pile of documents with no clear definition of whose responsibility any of it is is a sure way to get that pile of documents rejected.

Unfortunately, this might not be as easy to fix as simply putting a name on the papers. If the owner is assigned and just not recorded, that’s one thing. If they weren’t assigned before, and now it’s a new responsibility, that simply pushes the point of failure to a different area of the audit.

Contradictions in Redundant Documentation

Another common reason for rejected documentation is when the documentation you hand over to your auditor includes multiple different ways of the same thing being documented.

This is a failure on multiple levels. For one thing, it’s a failure to ensure that your documentation package is correct. Having multiple documents for the same control means that you didn’t have anyone review the documentation package before handing it over, which further indicates additional organizational problems.

It’s also a failure of the processes or systems you used to gather documentation in the first place. Another common problem with organizations seeking any sort of security framework compliance is not having a way to centralize document and artifact collection. Whether it’s one person forgetting they submitted it and adding another, or multiple people thinking they have to submit the same artifact, or simply no control over recognizing when documentation exists, it’s a fault.

This is a big part of what the Ignyte Assurance Platform does, for example. We provide a centralized, framework-agnostic, non-siloed way for different teams and collaborators to work together to generate and store things like documentation and proof artifacts. When your checklists get long, having a centralized way to track them all is very useful.

All of that is simply indicated by the presence of duplicate documentation. When it comes to comparing the actual documentation, the auditor then has to be intensely skeptical of anything that is different between them. If multiple documents for the same process say different things, which one is correct? It almost doesn’t matter if you’re not sure which is the right document to hand over.

Outdated Documentation

A similar issue to duplicated documentation is outdated documentation.

Yes, it can take a while to achieve ISO 27001 compliance. Many organizations take 6-12 months for their initial certification.

During that time, a common problem is compiling documentation too early. If you’re gathering documents of processes or proof that can change along the way, that documentation might look like it’s fulfilling the requirements, but it’s outdated and doesn’t actually say what you need it to say.

This is why you need document controls and change logs for your documentation. A system that can tell you when documentation is growing stale – or use internal APIs and other access to automatically update on a schedule – can be very important.

At the very least, you need to have a thorough review at the end of the process, before the audits, to validate the documentation you’re preparing to hand over.

Missing Documentation for Critical Proof

Missing documentation is, of course, also a cause for rejection. Auditors will expect documentation of critical processes, and if you have gaps in what you deliver, you’re going to have problems.

This is less of a rejection of documentation, though, and more of a rejection of your application.

Subjective Documentation

Something we’ve talked about in the context of CMMC before is the difference between subjective documentation and objective documentation.

An ISO 27001-relevant example might be for employee onboarding with associated security training.

A common problem is thinking that “we have onboarding with security training” as an attestation from HR is valid documentation. Unfortunately, a statement that a policy is in place is not proof of that policy.

Instead, your documentation needs to be more objective. It needs to, for example, include logs of the training modules passed by the employees being onboarded, logs of meetings they’ve had about it, or similar proof.

The exact proof you need varies depending on how the process is handled, as well.

What to Do if Your Documentation is Rejected

If you’ve started the auditing process and your documentation is being rejected, what can you do?

It depends on why the documentation is rejected.

If it’s being rejected because of simple details or contradictions that can be fixed, your auditor will generally give you the opportunity to fix them. Something as simple as an outdated document – especially when the updated document is easily available – is an easy fix.

Don’t think that faults like this are meaningless, though. They still indicate an underlying flaw in how you manage your documentation, which reflects how you manage your other policies. Even if you can fix it, it might still be a strike against you.

On the other hand, if your documentation is rejected not because of what it is, but what it says, it can mean you’re failing the audit for other reasons. A rejection of how your ISMS functions, if it fails to uphold the goals of ISO 27001, means you’re in for much more remediation.

We recommend checking out the Ignyte Platform to help alleviate the first of these two reasons. When all of your documentation is timestamped and stored in the same place, it can eliminate cases of duplicate or outdated documentation with ease, and there are a lot of other features besides. We’re also more than happy to show you what it can do for you, so book a demo today.