If I want to quickly get a first picture of the digital control of an organisation, I often pass a limited number of topics.

A few good questions quickly make it clear where the real uncertainty is and help determine whether further research is needed.

For management or management, it is often a question of risk, responsibility and continuity. An IT manager will automatically look more at technical operation and management.

This checklist brings these two perspectives together.

My advice with any .ja. or .green . reply is simple:

Ask where that proves.

That's where demonstrable control begins.

The 12 questions in one overview

No. Question Why this matters
1 Do we know which digital risks can hit our core targets the hardest? Without a risk picture, prioritizing becomes difficult.
2 Is it clear who owns those risks? Security without ownership often stays behind.
3 Do only the right people have access to critical systems? Abuse of accounts remains an important attack path.
4 Do we keep systems and configurations safe? Management determines whether security works structurally.
5 Do we find and remedy vulnerabilities in time? Open vulnerabilities are building up risk.
6 Do we see any suspicious events on time? Without detection, an incident can go unnoticed for a long time.
7 Can we prove our ability to repair critical systems? Backup is only valuable when recovery works.
8 Do we know what we're doing in a cyber incident? Under time pressure, unclear roles quickly become visible.
9 Do we have a grip on critical IT providers? Sub-contractors move work, not the business risk.
10 Do daily practices connect to policies? Security only works as agreements in practice countries.
11 Do we have proof that controls are actually being carried out? Assumptions give less certainty than detectable effect.
12 Does management get information that it can send to? Risks must lead to choices, ownership and follow-up.

1. Do we know which digital risks can hit our core targets the hardest?

This is always a good starting question for me.

Not:

“What cyber threats exist?”

Well:

.

Remember:

  • services to clients or customers;
  • production;
  • financial processes;
  • planning;
  • access to files;
  • communication;
  • logistics;
  • essential suppliers.

What do I want to see?

Examples include:

  • a summary of critical processes;
  • relevant systems;
  • supplier dependencies;
  • risk analysis;
  • Prioritised risks;
  • identified risk owners.

Follow-up question for management/direction

What three digital risks are the top priority and why?

If that does not come up with a clear answer, I would first tighten up the risk picture.

2. Is it clear who owns those risks?

I regularly come across formulations like:

.That's in IT.

That's often too easy.

IT can implement a measure. The business risk is wider.

So ask:

  • who owns the risk;
  • who is implementing the measure;
  • who decides on the budget;
  • who accepts residual risk;
  • who's receiving escalation.

What do I want to see?

  • rolls;
  • responsibilities;
  • decision-making;
  • risk ownership;
  • escalation agreements.

For a board member, this is mainly a question of governance.

For the IT manager, it gives clarity about who ultimately makes choices when technology, money and risk clashes.

3. Do only the right people have access?

Access seems to be a basic measure. That is precisely why we quickly assume that this will be settled.

I'd check at least:

  • multi-factor authentication;
  • management accounts;
  • increased duties;
  • accounts of former employees;
  • supplier accounts;
  • service accounts;
  • periodic access reviews.

A simple practice test

Request a current overview of:

  • administrators;
  • external accounts;
  • accounts without recent activity.

Then see if anyone can explain why every account is still needed.

That often yields more than just reading a procedure.

4. Do we keep systems and configurations safe?

An environment can be technically well set up and slowly deteriorate if management slackens.

So look at:

  • current assets;
  • safe configurations;
  • Endpoint management;
  • network segmentation;
  • encryption;
  • external access;
  • cloud settings;
  • management interfaces.

Ask for the IT manager

Which configurations are centrally monitored and where can systems deviate unnoticed?

This makes it visible whether security is part of structural management.

5. Do we find and remedy vulnerabilities in time?

Every organisation has vulnerabilities.

The interesting question is how quickly and purposefully they are followed.

Check:

  • which systems are scanned;
  • the time limits applicable;
  • who sets priorities;
  • the exceptions that exist;
  • which points have long been open;
  • how suppliers are addressed.

Question I like to ask

What critical vulnerabilities are still open, and why?

A good answer usually contains:

  • impact;
  • owner;
  • temporary control;
  • Date of resolution.

6. Do we see any suspicious events on time?

Security monitoring can be technically complex.

For management the question does not have to be technical.

I'd like to know:

  • which critical systems are monitored;
  • who assesses reports;
  • what happens outside office hours;
  • how incidents are escalated;
  • whether logs are available for research.

Question for management/direction

How long could an attacker be theoretically active with us before anyone notices?

Not always easy to answer, but a useful direction of thought.

7. Can we prove our ability to repair critical systems?

This is a subject I like to look at evidence on.

Not just:

♪ We're backing up every night ♪

Well:

  • when was last recovered;
  • which has been restored;
  • how long it took;
  • which dependencies emerged;
  • Is that recovery time consistent with the business?

Practical question

Show me the last restore test.

If there isn't, you know where uncertainty is.

8. Do we know what we're doing in a cyber incident?

An incident response plan can be perfectly prepared.

I want to know if people can work with it.

Check:

  • who is the incident leader;
  • who informs management/direction;
  • who is the supplier;
  • who makes communications;
  • who assesses legal/privacy aspects;
  • which external specialists are available;
  • or scenarios have been practiced.

Question for management/direction

What does the organisation expect from us in the first two hours of a serious incident?

That question makes roles clear fast.

9. Do we have a grip on critical IT providers?

Many organisations are digitally dependent on parties that they have little operational impact on.

Therefore, check:

  • critical suppliers;
  • access;
  • security arrangements;
  • incident reports;
  • repair arrangements;
  • Insurance;
  • subcontractors;
  • exit possibilities.

Question I would ask

Which supplier can stop our services most and what proof do we have that the party is in a position to control?

This is often a more administratively relevant demand than a generic supplier score.

10. Do daily practices connect to policies?

A policy can be neat.

Practice can run differently.

For example, look at:

  • onboarding;
  • offboarding;
  • amendments;
  • handling sensitive information;
  • awareness;
  • reporting behaviour;
  • function separation;
  • exceptions.

Practical test

Take one recent employee who has retired.

Check:

  • account;
  • equipment;
  • access to external systems;
  • group rights;
  • physical means.

You'll see immediately if the process actually works.

11. Do we have proof that controls are actually being carried out?

This is one of the most important questions in the list for me.

With every important measure I like to look at:

Design

Is the measure appropriate?

Existence

- Has it actually been introduced?

Operation

Does he work in practice?

Examples of evidence:

  • account reviews;
  • Restore tests;
  • incident records;
  • patch reports;
  • vulnerability scans;
  • supplier reviews;
  • management assessments;
  • Management reports.

A green status without underlying evidence would always be investigated further.

12. Does management get information that it can send to?

A technical report can be excellent and yet have little board-level value.

For management/direction I want to be able to see at least:

  • main risks;
  • serious open findings;
  • ownership;
  • deadlines;
  • residual risk;
  • delays;
  • supplier dependencies;
  • incidents;
  • recovery capability.

The core is:

What decision does attention need?

If a dashboard only shows figures and does not support a decision, there is still a translation.

How would I use this checklist myself?

Not as a hundred percent test.

I would use three possible outcomes per question:

Green

We know how this is arranged and can show the operation.

Orange

Something has been arranged, but evidence, ownership or execution is not yet sufficiently clear.

Red

Control is lacking or gives too little certainty to the risk.

Add at each orange or red point:

  • risk;
  • possible impact;
  • owner;
  • measure;
  • priority;
  • time limit.

Then the checklist becomes immediately usable for follow-up.

When do you need more than this self-check?

A checklist is useful to get questions up.

There are situations where I would go on.

For example, when:

  • The management wants independent insight;
  • requires a verifiable assurance;
  • require evidence from the client;
  • there is doubt about an IT supplier;
  • a major change is taking place;
  • incident level;
  • point out to each other several parties;
  • policy appears to be in order, while its operation remains uncertain.

Then a targeted audit, assessment or risk analysis can provide more certainty.

For boards and executive management and IT the questions are different

I deliberately use the same checklist for different functions, but the emphasis differs.

Management/Directory

I'm looking at that mostly:

  • risk;
  • continuity;
  • ownership;
  • suppliers;
  • evidence;
  • residual risk;
  • decision-making.

IT Manager

This is more often emphasised:

  • Technical scope;
  • management;
  • patching;
  • logging;
  • accounts;
  • restore;
  • monitoring;
  • Follow-up.

A good audit connects that perspective.

My main control question

If I could ask just one follow-up question after this checklist, it would be this one:

.What does that prove? .

This question quickly makes it clear whether an organisation relies on assumptions or has a real view of the functioning of its security.

You want to know how I build up a wider investigation? Read:

What is being investigated in an IT security audit?

Do you want to have independent testing of how technical and organisational measures work in practice? Then look at the Cyber Security Audit of Kynexis.

Sources and read on

What is an IT security audit investigating? →When do you choose a baseline assessment, assessment or audit? →Design, existence and operation →