Why organisations should test their own attack surface, access paths and recovery controls before an attacker finds the weakness first
Following on from my previous cybersecurity article, I wanted to look at something businesses still do not talk about enough: properly testing their own systems before an attacker does it for them.
A lot of cybersecurity is understandably focused on protection.
- Firewalls.
- MFA.
- Endpoint protection.
- Patching.
- Access controls.
- Backups.
All of these matter.
But there is another question businesses should be asking:
If somebody wanted to get into our systems today, where would they try first?
That is where security testing becomes important.
Because one of the worst times to discover a weakness is after somebody else has already found it.
Three key takeaways
- 1.Security testing is most useful when it shows what an attacker could reach after the first weakness, not just whether one vulnerability exists.
- 2.The attack surface includes old accounts, internet-facing services, third-party platforms, APIs and cloud identities, so access and ownership need regular review.
- 3.Testing should sit alongside ongoing vulnerability management, patching, monitoring, backup recovery tests and human-process checks rather than being treated as a once-a-year exercise.
Security testing is about finding the route in
When people hear terms such as “penetration testing” or “ethical hacking”, it can sound like something reserved for large organisations or specialist security teams.
The principle behind it is actually quite straightforward.
You are trying to understand how somebody could get into your systems before a real attacker does.
That might mean looking for:
- exposed services
- outdated applications
- weak authentication
- excessive permissions
- old administrator accounts
- misconfigured cloud services
- forgotten test systems
- insecure third-party access
- poor network segmentation
- weak API security
- credentials that should no longer be active
The important part is not simply finding a vulnerability.
It is understanding what could happen next.
A weakness on one system might not look particularly serious on its own. But could it lead to another account? Could that account access another system? Could that system reach customer data?
Could an attacker use one relatively minor weakness as the starting point for moving further through the network?
That is where an ordinary vulnerability can become a much bigger problem.
A vulnerability does not always look dramatic
I have seen this through my own cyber security work.
While using Microsoft Defender Vulnerability Management, I identified four managed Windows devices affected by a high-severity Microsoft Edge vulnerability with a CVSS score of 8.8.
On paper, that sounds serious.
The actual remediation was much less dramatic:
Identify the affected devices. Update the browser. Restart where required. Check Defender again.
That is the point.
The value came from finding the weakness before somebody had the opportunity to exploit it.
You do not want to discover during an incident investigation that a machine was vulnerable simply because an update had been missed.
You want to identify that weakness first.
The same principle applies to security testing more broadly.
What would an attacker see from the outside?
One of the most useful ways to think about security is to stop looking at your environment from the administrator's point of view.
Instead, look at it from the outside.
What is publicly visible?
What services are exposed?
What login pages can be found?
Which domains and subdomains exist?
Are there old services nobody remembers?
Is Remote Desktop exposed?
Is there a VPN appliance that has not been updated?
Are test systems accessible from the internet?
Are default configurations still being used?
In my networking work, I looked at how exposed RDP services can create opportunities for brute-force attacks and credential stuffing.
Having port 3389 open does not automatically mean a business will be compromised.
But it gives an attacker somewhere to start.
And generally, the fewer places you give somebody to start, the harder their job becomes.
The problem with forgotten access
Old access is another area businesses need to pay close attention to.
A user leaves the company.
Someone changes role.
A supplier finishes a project.
A temporary administrator account is created.
An application is retired.
Then, months later, nobody is completely sure whether the access was ever removed.
This is exactly the kind of thing security testing and regular access reviews should uncover.
I previously developed a PowerShell script to review local administrator accounts across Windows devices. The objective was simple: identify elevated access that might no longer be required.
That might not sound like penetration testing in the traditional sense, but it comes from the same mindset.
Find the unnecessary route before somebody else uses it.
Least privilege is not only about controlling what legitimate users are allowed to do.
It is also about limiting what an attacker could do if one of those accounts was compromised.
Back doors are not always deliberately created
When people hear the term “back door”, they often picture hidden malicious code.
Sometimes that is exactly what it means.
But in a business environment, the practical back door can be much more ordinary.
An old admin account.
A remote-access tool.
A forgotten API key.
A service account with a password that never expires.
An overly permissive firewall rule.
A third-party application with too much access.
A shared account nobody really owns.
A development environment that is still connected to production.
None of these things needs to have been created maliciously.
At the time, there may have been a perfectly legitimate reason for them to exist.
The problem comes later, when they are forgotten.
That is why a security review should not only ask:
“Is this technically working?”
It should also ask:
“Does this still need to exist?”
The ASOS incident is a good example of why this matters
The recent ASOS incident provides a useful example.
ASOS confirmed that an attacker gained access to an employee account by impersonating a trusted contact and obtaining login credentials.
Those credentials were then used to access information held on certain third-party platforms used by ASOS.
The company said some customer information, including names and contact details, was accessed, although payment-card details and account passwords were not compromised. It also said its website and app remained safe to use.
One of the more unusual parts of the incident was that customers received an unauthorised push notification through the ASOS app itself.
So this was not simply somebody sending a fake phishing email while pretending to be ASOS.
The attacker had gained enough access to misuse part of the company's own communications chain.
That is what makes the incident particularly relevant from a security-testing point of view.
The initial weakness appears to have involved a person being deceived.
Somebody was impersonated.
Credentials were obtained.
But the important question after that becomes:
What could those credentials reach?
That is exactly what good security testing should help an organisation understand.
If one employee account is compromised:
How many systems can it access?
Which third-party platforms trust it?
Can it send customer communications?
Can it access sensitive data?
Can it create new credentials?
Can it move laterally into other systems?
And how quickly would abnormal use be detected?
The issue is not only whether somebody can obtain a password.
It is what that password allows them to do afterwards.
Third-party platforms are part of your attack surface
The ASOS incident also highlights something else businesses need to consider.
Your attack surface is no longer just your own network.
Modern businesses depend on large numbers of third-party platforms.
CRM systems.
Cloud storage.
Marketing tools.
Analytics platforms.
Payment providers.
Support platforms.
Email systems.
Notification services.
Every connection between those systems creates another relationship that needs to be understood and controlled.
ASOS said the compromised credentials were used to access certain third-party platforms, while Snowflake stated there was no evidence that its own platform had been breached.
That distinction matters.
A third-party platform does not necessarily need to be “hacked” for an attacker to use it.
If somebody obtains valid credentials with sufficient permissions, they may simply walk through the front door.
That is why organisations need to test more than infrastructure.
They also need to review:
- third-party permissions
- API connections
- service accounts
- authentication methods
- conditional access
- token lifetimes
- administrator roles
- logging
- unusual sign-in alerts
- offboarding processes
You cannot properly protect something if you do not know it is connected.
Security testing should assume one control will fail
One of the biggest lessons from my cyber security work is that no single control should ever be relied upon completely.
The same principle should apply to testing.
Do not only ask:
“Can somebody get through the firewall?”
Ask:
“What happens if they already have a password?”
Do not only ask:
“Do we have MFA?”
Ask:
“What happens if somebody steals a session token?”
Do not only ask:
“Is endpoint protection installed?”
Ask:
“What happens if it is disabled?”
Do not only ask:
“Do we have backups?”
Ask:
“Can we actually restore them?”
And do not only ask:
“Do we monitor sign-ins?”
Ask:
“Would we recognise a genuine attacker among normal user activity?”
Good security testing works on the assumption that eventually one control may fail.
The objective is to make sure another control is waiting behind it.
Test the human side as well
The ASOS incident is another reminder that security testing cannot focus only on technology.
People are part of the security environment too.
That does not mean blaming employees when something goes wrong.
Social engineering and impersonation attacks are deliberately designed to exploit trust, urgency and normal human behaviour.
That means testing should also cover things such as:
- phishing simulations
- suspicious call scenarios
- password-reset procedures
- identity-verification processes
- helpdesk procedures
- supplier verification
- escalation processes
If somebody calls the service desk pretending to be a senior manager, what happens?
If someone says they have lost access to MFA and urgently need it reset, what checks are carried out first?
If a supplier suddenly asks for credentials or requests a configuration change, how is their identity verified?
Those processes need testing just as much as ports, firewalls and vulnerabilities do.
The goal is not to prove that everything is secure
I think this is where organisations sometimes approach security testing in the wrong way.
A penetration test should not be treated as an exam that the IT team needs to pass.
Finding weaknesses is not failure.
In many ways, finding them is exactly the point.
You want the security tester to identify the forgotten account.
You want them to find the exposed service.
You want them to discover the overly permissive role.
You want them to demonstrate that a standard user account can reach somewhere it should not.
Because every weakness discovered during an authorised test is something that can be fixed before a real attacker finds it.
That is far better than discovering the same weakness in an incident report six months later.
Security testing should not be a once-a-year exercise
Another mistake is treating security testing purely as an annual compliance requirement.
A business environment can change enormously in twelve months.
New systems are introduced.
New cloud services are connected.
Employees join and leave.
Permissions change.
New APIs are created.
Firewall rules are updated.
Suppliers are added.
Software versions change.
A penetration test carried out last year tells you what the environment looked like last year.
That is why security testing needs to sit alongside continuous activities such as vulnerability management, patching, access reviews, monitoring and configuration management.
You do not need to run a full penetration test every week.
But you should continually be asking whether your attack surface has changed.
If I was reviewing a business, these are the questions I would start with
Where can somebody log in from the internet?
Which accounts have administrator privileges?
Are there accounts nobody can explain?
Which third parties have access to company systems?
What happens when an employee leaves?
Which services are publicly exposed?
When were backups last restored and tested?
What software is currently vulnerable?
Can one compromised workstation reach critical servers?
Would we detect an unusual sign-in?
Can employees recognise and report social engineering?
What happens if MFA needs to be reset?
What systems can a normal employee account access?
Those questions do not require somebody to immediately start trying to hack the network.
They help you understand where the real risks might be.
Find it before they do
The ASOS incident is still being investigated, so it would be wrong to pretend that every technical detail is already known.
What is clear from the information available is that compromised employee credentials were enough to provide access to third-party platforms and customer information.
ASOS moved quickly to restrict access to the affected platforms and involved internal and external specialists, law enforcement and regulators.
But the wider lesson applies to any organisation.
Eventually, somebody may look for the easiest route into your systems.
It could be a vulnerable application.
It could be an old account.
It could be a supplier.
It could be an employee who is tricked into handing over their credentials.
Or it could simply be a service everybody forgot existed.
The best time to find that route is before they do.
Cyber security is not only about building higher walls.
It is also about regularly walking around your own building and checking whether somebody has left a door open.
And sometimes the most valuable thing a security test can tell you is not that every defence worked.
It is that you found the back door while there was still time to close it.
Work with InteliSense IT on cyber security testing and resilience
Security testing is most valuable when it connects technical findings to the systems, accounts and business processes that matter.
InteliSense IT can help organisations review their external attack surface, vulnerability-management process, identity and access controls, third-party access and recovery readiness, then turn the findings into a practical remediation plan.
The aim is not to create a longer list of risks. It is to identify the routes that matter most, close unnecessary access and verify that the controls behind them actually work.
Frequently asked questions
What is cyber security testing?
It is the authorised process of looking for weaknesses in systems, identities, configurations and processes so they can be fixed before they are exploited.
Is penetration testing the same as vulnerability scanning?
No. Vulnerability scanning is usually automated and helps identify known weaknesses at scale. Penetration testing is a scoped human-led assessment that can explore how weaknesses might be combined and what an attacker could reach.
How often should security testing be carried out?
The frequency should reflect risk and change. Vulnerability assessment should be ongoing, while penetration testing is commonly repeated after major changes, new internet-facing services or where assurance is needed that controls still work.
Does MFA remove the need for security testing?
No. MFA is an important control, but testing should also consider stolen sessions, excessive permissions, weak recovery processes, third-party access and what a compromised identity could reach.
What should happen after a security test?
Findings should be prioritised, assigned to an owner, remediated and then verified. Temporary mitigations should also be monitored until a permanent fix is in place.
Start by asking where an attacker would try first
A useful first step is to map what is exposed to the internet, which accounts hold privileged access, which third parties are trusted and which systems would matter most if one identity or endpoint were compromised.
From there, test the controls around those routes, fix what does not need to be exposed and verify the remediation. That gives the organisation evidence about its real attack surface rather than an assumption that every control is working.
Sources
- ASOS Customer Care — Latest information about the unauthorised ASOS notification: https://www.asos.com/customer-care/engagement/unauthorised-asos-notification/
- Reuters — UK’s ASOS says cyber hack accessed customers’ personal data, 8 October 2026: https://www.reuters.com/business/retail-consumer/uks-asos-says-breach-exposed-some-customer-personal-data-2026-10-08/
- National Cyber Security Centre — Vulnerability management guidance: https://www.ncsc.gov.uk/collection/vulnerability-management/guidance
- National Cyber Security Centre — External attack surface management buyer’s guide: https://www.ncsc.gov.uk/guidance/external-attack-surface-management-buyers-guide
- National Cyber Security Centre — Penetration testing guidance: https://www.ncsc.gov.uk/section/advice-guidance/all-topics/penetration-testing
