Penetration testing is a form of ethical hacking where specialist testers deliberately attack a system on behalf of the organisation that owns it. They use the same kinds of techniques and tools as real attackers, but their aim is to find vulnerabilities before a criminal does, so they can be fixed, patched or otherwise mitigated.
A test can look at operating systems, applications, program code, authentication, network configuration, encryption and physical security. It shows whether an attacker can gain access, how far they can get once inside, and what they could do — for example, whether someone could reach the membership records of a youth football club and change players' contact details.
| Type | Who it simulates | What it checks |
|---|---|---|
| External | Someone outside the organisation | Systems reachable from outside, such as a club's online payment page |
| Internal | Someone who already works for the organisation and has an ordinary login, such as a temporary cover teacher's account | What one standard account could reach or change, showing the damage if an account were misused — for example, whether it could open the exam results folder as well as the class register |
Testers gather information about the target and identify possible entry points before attempting to break in. If they get access, they may exploit a weakness to demonstrate the risk is real, but never in a way that disrupts the system — a shop's online ordering service must keep taking orders throughout.
Every issue is documented and security improvements are recommended, then reported to the organisation so security and employee practices can improve. Testing is repeated until security reaches a suitable standard, and any change to a system should be tested again, because new features can reopen old gaps. This helps ensure updates, patches and fixes are installed, improves incident response because staff are better prepared, and measures how strong security really is.
Organisations collect data about how their systems are used and then look for patterns that suggest a risk — something that could lead to unauthorised access, or to data being lost, stolen or changed. Analysing that data turns a pile of records into evidence you can act on. Each source reveals a different kind of behaviour.
| Method | What it records | Risk it can reveal |
|---|---|---|
| Access logs | Who logged in, when, from where, and which files they opened | An account logging in at 3am when that user only ever works daytime hours |
| Browsing history and network traffic | Sites visited, files downloaded and uploaded, and how much data is moving | A large upload to an unfamiliar site — data leaving the organisation |
| Content or word filters | Pages and search terms users tried to reach, including blocked ones | A user repeatedly searching for ways to break into accounts |
| Monitoring software or screen sharing | What is on a user's screen, live, as they work | Customer records being pasted into a personal email |
| Scanning storage areas | Files saved on drives and shared folders | An unauthorised copy of a database sitting where it should not be |
| CCTV or direct observation | What people are doing physically in the building | A password stuck to a monitor that any visitor could read |
A single odd record usually means nothing. Analysis is about patterns: an account failing to log in twenty times in a minute, or one department downloading far more than everyone else. Those patterns point to a possible attack or to someone breaking the rules.
The results show whether security policies are actually being followed and where improvements are needed. If logs show that half the staff in one office share a single login, the policy on personal accounts is not working, so training or tighter account rules are needed.
Blocking websites restricts what users can reach, but it is not a method of monitoring. Nothing is recorded and nothing is reviewed, so you learn nothing about what people are actually doing.