The Big Fight With The Auditor

The room was silent.

The kind of silence you feel in your chest. Patrick looked around the table. The CEO. The CFO. The CTO. All of them staring at a young auditor who had just, in a single sentence, threatened to unravel eighteen months of work.

"Based on my findings, I'm recommending the organisation not receive its certificate."

Patrick had been in infosec long enough to know that silence in a boardroom is never a good sign. But this silence was different. This one had a question buried inside it.

Does this kid actually know what he's talking about?

As it turned out, he did not.

Let's rewind.

Patrick's company needed ISO 27001 certification. Not as a nice-to-have badge on their website, but as a hard commercial requirement. Government contracts were on the line. The kind of contracts that change a company's trajectory. Without the certificate, those doors stayed shut.

So Patrick did everything right. He built a real Information Security Management System, not a compliance tick-box exercise. He ran risk assessments, put controls in place, got buy-in from leadership, and made sure the ISMS was actually operational. He hired a reputable Certification Body with a strong track record.

For the stage 2 audit, The Certification Body sent him a young auditor. Fresh-faced, confident, clearly smart. Patrick got the impression this might have been the auditor's first solo engagement, but he didn't hold that against him. Everyone starts somewhere.

The audit had been going smoothly. Patrick and his team were open and cooperative. Evidence was provided. Questions were answered. It felt, by all accounts, like it was going well.

Then came the close-out meeting.

Because of how much was riding on this audit, Patrick had asked the executive team to attend the close-out. That is how you end up with a CEO, CFO, and CTO all sitting in a conference room waiting to hear whether months of work had paid off.

The auditor opened professionally. He thanked Patrick and the team for their time. He acknowledged the quality of the documentation. He complimented the maturity of the ISMS.

And then he dropped the hammer.

He had identified several nonconformities. Specifically, nonconformities against Annex A controls. And on the basis of those nonconformities, he was not prepared to recommend certification.

The silence hit the room like a pressure wave.

Patrick kept his composure. He asked the auditor a straightforward question.

"Were the risks adequately identified?"

The auditor nodded. Yes, the risk assessment was thorough.

"Were appropriate controls selected and implemented to mitigate those risks?"

The auditor hesitated, then confirmed. Yes, the controls were appropriate.

Patrick asked him to walk through the specific findings.

The first nonconformity: not every employee had completed their annual security awareness training.

Patrick explained that several staff members were on maternity or paternity leave. They were not in the building. They had not been forgotten; they were scheduled to complete the training on their return.

The auditor wrote something down and moved on.

The second nonconformity: automated patching had failed on a number of laptops.

Patrick explained that the failures had been caught by the monitoring and alerting systems, flagged immediately, and patching had been manually applied within the defined SLA window. The control had not failed. The detection and response mechanism had worked exactly as designed.

The auditor's confidence was visibly wilting. He was no longer the assured young professional who had walked into the room an hour earlier. He had the look of someone doing arithmetic in their head and not liking where the numbers were going.

He started to dig in anyway, because sometimes people dig in when they should step back. Patrick gave him the opening he needed to do the latter.

Patrick leaned forward.

"Before we continue, I want to raise something important about how nonconformities work under ISO 27001."

He explained it clearly.

ISO 27001 has mandatory requirements. They live in clauses 4 through 10: context, leadership, planning, support, operation, performance evaluation, and improvement. These are the obligations an organisation must fulfil to achieve certification. Nonconformities can only be raised against mandatory requirements.

Annex A is different. Annex A is a reference set of controls. It is not a checklist of obligations. Organisations use it as a starting point during risk treatment to make sure they have not overlooked relevant controls. They document their selections, and their exclusions, in the Statement of Applicability. But implementing every Annex A control is not a requirement. Choosing not to implement a control is entirely acceptable, as long as the risk is understood and the decision is documented.

More importantly, auditors do not audit against Annex A controls in isolation. They audit against whether the organisation has a functioning risk management process, has selected appropriate controls to treat identified risks, and has implemented those controls effectively.

Patrick had done all of that. The auditor had already confirmed it.

"If the risks have been identified and appropriate controls are in place and operating," Patrick said, "then there is no basis for a nonconformity, regardless of whether a specific sample failed."

The auditor had no counter-argument. He tried to find one. He could not.

After a pause that felt much longer than it was, he acknowledged that the findings did not constitute true nonconformities under the standard. He thanked everyone for their time, gathered his materials, and left the building with considerably less swagger than he had arrived with.

The certification came through. The government contracts followed.

Patrick never heard from that particular auditor again, though he suspects the experience was formative for the young man. Or at least, he hopes it was.

Patrick's story is entertaining, but it carries a lesson that matters well beyond any single audit.

ISO 27001 is a risk-based standard. Its entire logic is built around the idea that different organisations face different risks, operate in different contexts, and therefore need different controls. Annex A exists to help you make sure you have thought through your options, not to give an auditor a checklist to score you against.

If you are going through ISO 27001 certification, understand what is actually mandatory and what is not. Know your clauses 4 to 10. Know your Statement of Applicability. Know what your risk treatment decisions were and why you made them.

Because an auditor who does not understand the standard can still cause serious damage, even if they are wrong. They can delay your certification, undermine your credibility in front of your leadership, and send a room full of executives home thinking the whole effort failed.

Patrick knew the standard. That made all the difference.

Know yours.

One more thing before you go. If you're trying to get AI governance basics in place, I put together a free checklist that cuts through the noise. Grab it here: https://infosecnerd.com/products/ai-blueprint