The Security Question Every Organisation Should Be Able To Answer 

One practical question quickly tests an organisation’s cybersecurity confidence: 

If an attacker gained access through one user account today, how far could the compromise go before your organisation detected and contained it? 

For executives and IT leaders, the answer reveals whether security confidence is backed by evidence or assumption. 

Why assuming ‘we’ve got that covered’ can hide real exposure 

Relying on a ‘we’ve got that covered’ assumption can lead organisations to overestimate their security posture and overlook how fast their cybersecurity environment changes. 

Security tools, audits, and dashboards all help organisations understand their environment, but their outputs do not always show how an attacker could combine weaknesses or move through it.

For example, organisations may cite an audit when evaluating their cybersecurity posture, believing it provides sufficient assurance.  

An audit can provide a point-in-time view of whether controls such as Multi-Factor Authentication (MFA) or documented policies are present, designed correctly, and operating within the audit’s scope.

An attacker looks at the same control differently: can it be bypassed, chained with another weakness, or misused in a way the organisation did not anticipate? MFA may be enabled, but is it consistently enforced across users, applications, guest access, privileged accounts, and authentication methods?

The difference between MFA being present and MFA being consistently enforced can be significant, and it’s this security gap that attackers exploit. The same applies to privileged access, where a single over-privileged administrator account can create a much larger blast radius than expected.

Audits can also quickly become outdated as new accounts, applications, exceptions, and temporary firewall rules reshape the security environment. How an organisation responds to an audit’s findings makes the difference. 

Controls need validation 

Security controls should be tested and validated against the scenarios they are meant to defend against. Over time, controls can degrade as exceptions are approved, users change, applications are added, temporary access remains in place, and detection rules are switched on but not thoroughly tested.

Configuration confirms a setting exists. Validation tests whether the setting works under realistic conditions. Asking whether MFA is configured is a settings check. 

Testing whether MFA can be bypassed under realistic conditions is validation. The same principle applies to alerts, where enabling a rule is only the starting point.

The real test is whether a rule fires, reaches the right person, and leads to action. Without validation, the organisation may be relying on controls that look effective but have never been proven. 

Attackers follow paths 

M365 compromise is often shaped by privilege and configuration as much as unpatched critical vulnerabilities. Security teams often work through lists: assets, controls, findings, vulnerabilities, remediation tasks. 

Meanwhile, attackers look for paths — and it’s this difference in approach that changes how risk should be understood. For example, a high-severity issue on an isolated system may be less useful for an attacker than a medium-risk issue elsewhere that provides a foothold into something more important. 

Attackers often use native tools and administrative utilities already available inside the environment. Because those tools are legitimate, attacker activity can blend into normal operations without obvious red flags. A breach rarely depends on one issue alone. Risk becomes more serious when several smaller issues line up. 

Speed and silence change the impact

When environments are tested realistically, it can be surprising how quickly and quietly activity can progress. 

An attacker could access sensitive information and remain undetected for months, only for the organisation to discover that a security alert was sent to a mailbox belonging to someone who had already left. 

Vendor connections, trusted supplier access, and SaaS platforms can become familiar enough that they stop being questioned.  

A provider may be responsible for securing its own platform, but the access granted into the customer environment remains part of the organisation’s risk surface. 

Findings need ownership 

While identifying issues is a start, reducing risk requires ownership, prioritisation, and follow-through. Findings often span IT, security, applications, infrastructure, and external providers, which can make ownership difficult to assign.  

As a result, remediation can be delayed by operational risk, tight change windows, legacy dependencies, or uncertainty about which team is accountable for the fix. 

The volume of findings can also create confusion, especially when teams measure closure rates instead of risk reduction. Easy fixes may be completed while more meaningful exposure remains. 

An assessment report can create awareness, but unless it becomes a prioritised, owned, and time-bound plan, it may not reduce risk. The more useful output is a clearer order of action: what matters most, who owns it, and how the organisation will confirm the fix worked. Closing findings is different to reducing risk. 

From assumed security to proven resilience 

Effective security operates as a continuous feedback loop, rather than a project with an end date.  

Controls are reviewed, exposure is tested, findings are prioritised, fixes are validated, and regression is checked over time.  

The goal is to prove that controls, detection, and response will work when needed.

The security question leaders should be able to answer is simple: 

If an attacker gained access through one user account today, how far could the compromise go before your organisation detected and contained it?

If the answer is unclear, the next step is to turn assumptions into evidence.