“Do you encrypt your endpoint devices?”

“Yes. We use BitLocker.”

“Great. Show me. On that laptop, in front of you.”

The answer was correct. The organisation genuinely did encrypt its endpoints. And the room still went quiet, because the person answering had never once opened the tool they had just told an auditor they relied on.

Thirty seconds of work would have settled it — open BitLocker, show the drive is protected, show the recovery key is escrowed. Instead there was a scramble, a wrong menu, an apology, and a note in the auditor’s pad.

(A note on terminology: ENX calls this an assessment, carried out by an assessor. Almost everyone preparing for one calls it an audit, so that’s the word used here.)

Why TISAX audit preparation isn’t about documents

Most TISAX preparation is artefact preparation. Policies written, registers populated, evidence folders indexed and cross-referenced. All necessary. None of it sufficient.

A TISAX audit doesn’t ask whether a control exists. It asks at what maturity the control operates — and a verbal assertion is the least mature form of evidence there is. Your auditor cannot tell the difference between a control that works and a control that has been described to them. So they will make you do it, in front of them, on the spot.

Which means the questions below aren’t tricks. They’re the method.

1. TISAX evidence requirements: every “yes” becomes “show me”

Assume it, every time. For every control your team owns, someone should be able to name the screen that proves it — not the policy that describes it. The dashboard. The report. The console. The record.

The BitLocker failure above wasn’t a technical failure. It was a person who had inherited a claim and never verified it themselves.

Prepare: for each control you own, write down the single screen, report or record that demonstrates it — then open it once, before the audit, on the device you’ll be using.

2. TISAX audit questions go three levels deep

Answers earn follow-ups. Reliably three deep:

• “We scan for vulnerabilities.” → “Show me last month’s scan.”
• → “There are four criticals here. Show me the tickets.”
• → “This one’s ninety days old. Show me who accepted the risk, and when.”

Nobody gets caught at depth one. TISAX audits are won and lost at depth three, where the process either continues or quietly stops.

Prepare: take your five most confident claims and walk each one three questions deeper than feels necessary. Whatever breaks at depth three is your actual gap.

3. TISAX audit sampling: the auditor chooses the record, not you

Teams rehearse their best example. Auditors ask for a specific one: who was your last leaver? Show me that offboarding. Or they take a name off your staff list, an asset off your inventory, a supplier off your contract list.

And they ask for the latest rather than the tidiest, because recency is what shows a process is still alive rather than performed once, for the folder.

So the question isn’t “do we have a good example?” It’s “would any of them do?”

Prepare: know your last one — last leaver, last access review, last restore test, last tabletop, last supplier onboarded, last incident however trivial — with dates and evidence within a couple of clicks.

4. Live demonstrations: rehearse on the real system, with the real account

The most common way a live demonstration fails has nothing to do with the control.

The console needs an admin account behind just-in-time elevation that nobody has actually exercised in months. The MFA prompt goes to a phone belonging to whoever is on annual leave. The dashboard loads, but it’s the wrong tenant. Or — in a remote TISAX audit — someone shares their entire desktop and the room gets an unplanned look at a folder of client files, which is now an incident of your own making, during your own audit.

Prepare: dry-run every demonstration end to end, on the device you’ll use, with the account you’ll use, on the platform you’ll use. Share a window, never a screen. Close everything else first.

5. CCTV and time synchronisation: is your audit evidence forensically sound?

“Do you have CCTV?”

“Yes, here it is.”

“Show me the time clock.”

This one catches good organisations. The cameras are there. The footage is there. The clock is eleven minutes out and hasn’t been touched since the last daylight saving change.

Footage with an unreliable timestamp isn’t weak evidence. For forensic purposes it isn’t evidence. If it ever has to support a disciplinary process, an insurance claim or a witness statement, the first thing challenged is the time — and once time falls, the footage falls with it.

The same logic runs through everything else you’d rely on after an incident. Log timestamps. Door records against camera records. Whether your estate syncs to an authoritative time source, whether that sync is monitored, and whether the seasonal change is automatic or was somebody’s forgotten calendar reminder.

Prepare: confirm time is synchronised from a known source across the estate, that the sync is monitored, and that DST handling is automatic. Then reconcile two independent sources — a door log against the camera covering that door, same minute — and keep the screenshot.

6. TISAX document control: an undated policy is not a control

Auditors read footers first.

A policy with no version history, no named owner, no approval record and no review date tells them it was written for the audit rather than used by the business. That’s the difference between a management system and a folder of Word files.

And the follow-ups don’t vary: who approved this and where’s the record, when is it next due, show me the last review.

Prepare: sweep every in-scope document for owner, version, approval and review date. Where a review is overdue, either do it or record a dated, reasoned deferral — an honest deferral reads far better than a silently expired policy.

7. TISAX audit interviews: your process owners must tell the same story

Nobody is going to be stopped in a corridor. The interview list is agreed in advance and the auditor is speaking to the people who own the processes.

That’s not less exposure. It’s more — because process owners get asked about the same process from opposite ends.

The classic is offboarding. Your IT lead describes it as triggered by a ticket from HR. Your HR lead describes it as an email to the service desk. Both are accurately describing what they personally do. Neither is wrong. The process has a seam in the middle, and the auditor has just found it without opening a single document.

Anywhere a control crosses a functional boundary, expect the same treatment: joiners and leavers, escalation from the service desk to security to your data protection contact, supplier onboarding across procurement, legal and IT, physical access requests and approvals.

Then there’s the version of this aimed at any single interviewee: “who does this when you’re not here?” A process that lives in one person’s head is, by the maturity model, not established — it’s performed.

Prepare: get your interviewees in one room a week out and walk each cross-functional process end to end, out loud, in handover order. Wherever two people describe the same handover differently, you’ve found a finding — in time to close it, or at least to log it and own it.

8. Break-glass accounts: what TISAX resilience actually requires

“Do you have robust organisational resilience?”

“Yes.”

“Show me your break-glass account.”

A vault entry isn’t the answer, because the premise of break-glass is that your normal systems — including the vault, including your identity provider, including your network — may be precisely what’s unavailable.

True resilience is one of each: a credential retrievable digitally, and a sealed physical copy in a safe on site or held in escrow somewhere you can actually get to it at three in the morning.

Then come the real questions. Who is authorised to open it. How the seal is tamper-evident. When it was last tested. When it was last rotated — after it was used, or after the last person who knew it left.

Prepare: verify you hold both forms, that the physical copy is sealed and its access logged, and that retrieval and login have been tested at least once, with the test recorded and dated.

9. What should staff say when they don’t know the answer?

“I don’t know, but I know who does” is a professional answer. A guess is a finding.

Under pressure the instinct is to fill silence. Someone half-remembers a retention period and says seven years when the policy says three — and now there is a documented contradiction between what staff believe and what the process states. A finding that didn’t exist ten seconds earlier.

No auditor penalises an individual for not carrying the whole management system in their head. What they assess is whether the organisation knows where its answers live.

So give people the sentence, verbatim: “I don’t hold that detail — [name] owns it, and we can have it in front of you this afternoon.” Then actually deliver it that afternoon, because closing the loop fast is itself evidence of a functioning system.

Prepare: script that sentence, name the owner for every domain, and agree in advance who maintains the follow-up log during the audit.

10. Known gaps, risk registers and disagreeing with your auditor

Two failure modes here, pulling in opposite directions.

The first is defensiveness: arguing the requirement, relitigating a finding, trying to win the room. It burns audit time and reads as a governance problem rather than a technical one. If you disagree, ask which requirement is being assessed and offer further evidence — then accept the answer.

The second is anxious over-sharing: asked about laptop encryption, volunteering that removable media in the lab is a bit of a free-for-all.

Be completely truthful, always. But understand the difference between a gap the auditor discovers and a gap you have already found, risk-assessed, assigned an owner and given a date. The first is a hole. The second is proof your management system works. The week before the audit is your last chance to move items from the first category into the second.

Prepare: run your own honest gap review, put what you find on the risk register with owners and dates, and brief the team that “yes, we know — it’s item 14, owned by Sarah, due in March” is one of the strongest sentences available to them.

Preparing for a TISAX audit is preparing for a real incident

Not one of these ten items is about producing a document. Every one is about whether the thing you claim actually works when somebody makes you do it, in front of them, without notice.

Which is exactly the test an incident applies.

The break-glass credential you can retrieve at four in the morning. The camera timestamp that holds up when it finally matters. The offboarding you can evidence when a departed employee’s account surfaces in a log. The person who knows precisely who to call.

Your auditor is asking you to demonstrate the same small handful of capabilities you would need on your worst Tuesday — just with more notice, and better manners.

Prepare properly and you don’t get a certificate. You get an organisation that could survive the thing the certificate is about.

TISAX audit preparation: frequently asked questions

What questions do TISAX auditors ask?

Fewer than you’d expect, but each one repeatedly. Expect a claim to be tested by demonstration (“show me on that laptop”), then followed up two or three levels deeper into the process — the record, the exception, and who signed off the exception.

Do TISAX auditors interview all staff?

No. The interview list is agreed in advance and covers the people who own the in-scope processes. The risk isn’t a random employee being caught out — it’s two process owners describing the same handover differently.

What evidence do you need for a TISAX audit?

Documented policies are the starting point, not the finish. For each control you need a live artefact that shows it operating: the configuration screen, the dated record, the most recent instance of a recurring process, and the approval trail behind any exception.

Why do TISAX auditors ask you to demonstrate controls live?

Because TISAX scores maturity, not existence. A verbal assertion is the weakest evidence available, so an auditor has no way to distinguish a control that works from one that has merely been described. A live demonstration is the only thing that settles it.