What to Do When Auditors Ask for a Document That Isn't Required?
An auditor asks for a piece of paper, and your heart sinks. But what if they're wrong?
The audit is going smoothly. You’ve showed them your risk register. You’ve walked them through your access control procedures. You’re starting to relax.
And then, the auditor looks up from their notes.
“Can you show me your documented list of internal and external issues?”
Your stomach drops. You know you talked about those issues. You had a whole workshop. You have notes in a Confluence page somewhere... or maybe they were just on a whiteboard. Is this it? Is this the “major nonconformity” that’s going to fail your audit?
The auditor helpfully adds, “You know, for Clause 4.1. Understanding the organization and its context.”
You nod, but you’re already scrambling.
This happened to all of us.
But what if I tell you that you don’t have to have a documented list of internal and external issues? Let’s dive in.
What Many of us Get Wrong
According to ISO/IEC 27001:2022, Clause 4.1 requires your organization to determine these issues.
It does not say you must document them.
To “Determine” means you have to think about them, identify them, and understand them. The activity is what’s mandatory. An artifact, something like a single, formal, signed-off document, is not.
So why do auditors ask for it?
Because it’s easy. It’s the simplest way for them to get evidence that the activity happened. Many auditors live by the old saying, “If it’s not written down, it didn’t happen”. Asking for a document is faster than a 10-minute interview and a lot easier to submit as objective evidence.
But in this specific case, the standard is on your side.
Let’s say one of your internal issues (Clause 4.1) is that you run an old, unsupported legacy system in the basement. This will of course affect multiple aspects of your management system, especially the required competence of IT-administrators.
Instead of requesting a list of internal and external issues, auditors should look out for whether an organization is taking this into consideration when it comes to hiring new and training existing staff. In this example, the internal and external context would be extremely relevant for Clause 7.2 (Competence).
So, the problem isn’t always the standard. It’s the gap between the standard’s flexibility and the auditor’s traditional, document-centric habits.
What a “Nonconformity” Actually Is (And Isn’t)
Before we go further, we need to agree on what “failing” means. When an auditor finds something wrong, they raise a “nonconformity.”
A nonconformity is simply the “non-fulfilment of a requirement”.
This is the most important thing you will read today: In any audit, the auditor is checking for the fulfilment of two sets of requirements. Not just one.
ISO 27001 Requirements. These are the “shall” statements in the ISO 27001 standard. For example, Clause 5.2 says you shall establish an information security policy. If you don’t have one, that’s a nonconformity. This is the obvious one.
Organizational Requirements. These are the rules, policies, and procedures you write for yourself. If your Information Security Management System (ISMS) says you will do something, the auditor will check that you are, in fact, doing it.
👉 An auditor can only write a nonconformity if you violate a rule from one of these two sets.
So, if the standard doesn’t require a documented list (Set 1) AND your own ISMS policies don’t promise a documented list (Set 2)... then the absence of that list is not a nonconformity.
The Trap: How You Create Your Own Nonconformities
That second set of requirements—the ones you write yourself—is the biggest trap in compliance. And most people walk right into it.
We try to “over-document” to look good, but we just give the auditor more ammunition.
Let’s use an example. The standard requires you to “manage information security incidents.” That’s flexible. But you, trying to be impressive, write a mandatory company-wide procedure that says, “All incidents, of any severity, must be reported to the CISO within 15 minutes.”
You’ve just created a new, very specific, and very brittle requirement for yourself.
What happens when the auditor finds an employee who reported an incident after 30 minutes? You didn’t violate the standard, but you did violate your own procedure. And that is a 100% valid nonconformity.
This is the “Self-Imposed Requirement Trap.” It’s born from good intentions but paved with nonconformities. We write aspirational policies that don’t match our real-world operations.
This is why Clause 4.1 is such a perfect example. By not documenting it formally, you may reduce your audit risk—as long as you still did the work and can prove it. If you do document it, you’ve just created more administrative overhead, and thus, more ways to fail.
Why Doesn’t the Standard Just Tell Me What to Write Down?
At this point, you might be thinking, “This is silly. Why don’t the ISO people just give us a checklist?”
The answer is that modern standards like ISO 27001 are risk-based, not checklists. They are designed to work for a 10-person startup and a 100,000-person bank. The standard cannot know the “extent of documented information” you need. Only you can.
The standard trusts you to be the expert on your own company. It’s built for effectiveness, not just “a system of documents”.
But the standard isn’t trying to trick you. In fact, it has a “secret code” for when it absolutely, 100% wants you to write something down.
You just have to know the two magic phrases:
“Maintain documented information”: This is the code for a document. Think of policies, procedures, or the scope of your ISMS. These are “living” documents that you must “maintain” and keep up-to-date.
“Retain documented information”: This is the code for a record. This is evidence, or proof, that something happened. Think of audit results, management review outputs, or logs. You “retain” them to prove you did the work.
Now, go back and look at Clause 4.1. Does it say “maintain” or “retain”?
It says neither. It just says “determine.”
This is the standard’s authors explicitly telling you that the format is flexible. When they want a document, they know exactly what to say.
A Simple Guide: What ISO 27001 Actually Requires
So, let’s put this “secret code” to work. You don’t need a 50-page “Mandatory Documents” list. The standard is actually very specific. Here is a list of the main things ISO 27001:2022 explicitly requires you to document.
(And before you start the audit, just look at this list. Notice what isn’t on it? Clause 4.1.)
This isn’t everything: The most important one is to be found in clause 7.5: the documents you decide are necessary. That’s the trap from Section 4. Be thoughtful. Keep it simple.
The Bottom Line
That’s it. You’re not at the mercy of an auditor’s personal checklist. An audit is a verification of your system, not a test of your document library.
Your job is to build an effective Information Security Management System that actually manages risk. Part of that is having the right documentation—and not one page more than you need.
So be polite. Be confident. And most importantly, know the difference between what the standard requires, and what you promise.
Whenever you’re ready, there are 3 ways how we can help you:
ISO/IEC 27001 Lead Implementer Course: Learn how to implement, and maintain an ISMS. Leverage ready-to-use templates designed to accelerate your certification journey.
Exam Vouchers: Prepare and certify with confidence. Purchase exam vouchers and add official, exam-aligned training material. Save 10% compared to official retail prices.
Promote your business: Put your company in front of 7,000+ highly-engaged GRC professionals at a 51% open rate!