Penetration testing and the role of AI.

What penetration testing is

A penetration test is an authorised, simulated attack on an organisation's systems, carried out to find weaknesses before real attackers do. Testers use the same kinds of techniques as attackers, but with permission, within agreed limits, and with the goal of helping the organisation fix what they find.

It is often confused with related activities:

• Vulnerability scanning: automated tools that look for known weaknesses. Scanning is broad and frequent, but it does not show whether weaknesses can actually be combined and exploited.
• Penetration testing: skilled people, often helped by tools, attempting to exploit weaknesses and showing what an attacker could really achieve.
• Red teaming: a longer, goal-based exercise that tests not only systems but the organisation's ability to detect and respond, often without most staff knowing in advance.

Common types of test:

• External: systems reachable from the internet.
• Internal: what an attacker could do once inside the network, for example after a successful phishing email.
• Web application and API: the applications customers and partners use.
• Social engineering: testing whether staff can be tricked, for example with simulated phishing.
• Cloud and mobile: configuration and applications in cloud platforms and on phones.

A test is a snapshot: it shows the weaknesses found at one time, by one team, within one scope. The UK National Cyber Security Centre advises using a penetration test to gain assurance that your ongoing vulnerability management is working, not as the main way to find weaknesses.

Authorisation comes first

What makes a penetration test lawful, rather than an attack, is permission. Accessing a computer system without authorisation is an offence in most countries. In Kenya, section 14 of the Computer Misuse and Cybercrimes Act, 2018 makes it an offence to get into a computer system by getting round its security measures, knowing the access is unauthorised. Access is unauthorised when the person is not entitled to it and has no consent from someone who is. The maximum penalty is a fine of five million shillings, three years' imprisonment, or both. Heavier penalties apply where access is intended to commit a further offence (section 15) or where a system is interfered with (section 16). Section 18 exempts tools and access codes used for authorised testing or protection of a computer system, so written authorisation matters for your tools too.

Before any testing starts, there must be:

• Written authorisation from someone with the authority to give it, for every system in scope. If a system belongs to a third party, such as a cloud provider or a hosting company, check its rules too; your own permission may not be enough. Major cloud providers publish rules for testing on their platforms: many allow customers to test their own resources without asking first, but forbid some activities such as denial-of-service testing.
• A defined scope: exactly which systems, addresses and applications may be tested, and which may not.
• Rules of engagement: when testing may happen, which techniques are allowed or forbidden, how to avoid disrupting live services, and what to do if the tester finds something critical or finds evidence that a real attacker is already present.
• Contacts on both sides, available during testing, and a way to stop the test immediately.
• Data handling rules: testers may see personal and confidential data. Under Kenya's Data Protection Act, 2019 (section 42), an organisation that lets an outside tester handle personal data should have a written contract requiring the tester to act only on its instructions and to protect the data. Agree how data will be protected, kept and destroyed.
• Safety: before exploitation, confirm that backups exist and that the client knows how to stop the test, because disrupting a system without authorisation is itself an offence.
• For social engineering tests, agree in advance how staff results will be handled, so the test measures the organisation, not individual blame.

Choose testers with recognised, independently assessed qualifications and professional indemnity insurance, and check their references.

Staying strictly inside the scope is not a formality. Testing a system outside it, even by accident, can be illegal and can harm people who never agreed to it.

How a test is run

Established methodologies give tests a consistent structure. Examples are NIST's technical guide to security testing (SP 800-115, 2008), the UK National Cyber Security Centre's penetration testing guidance, and, for web applications, the OWASP Web Security Testing Guide (version 4.2). Methodologies divide the work differently (NIST's guide uses four phases), but most cover these steps:

• Planning and scoping: agreeing goals, scope, rules and timing.
• Reconnaissance: gathering information about the target, from public sources and from the systems in scope.
• Discovery and vulnerability analysis: identifying services, versions and potential weaknesses, often with automated tools, and checking which are real.
• Exploitation: carefully attempting to use the weaknesses, within the rules, to show their real impact.
• Post-exploitation: where allowed, showing what an attacker could reach next, such as sensitive data or wider access, without causing damage.
• Reporting: documenting what was found and how to fix it.

Good testers work carefully: they avoid actions that could disrupt live systems, record everything they do, and stop and call the client when they find something critical. The skill lies less in running tools than in judgement: recognising which findings matter, chaining small weaknesses into a realistic attack path, and explaining the risk clearly.

Reporting and fixing

The value of a penetration test lies in the fixes that follow it. A good report includes:

• An executive summary in plain language: the overall risk, the most serious findings and what they mean for the business.
• Findings, each with a description, the evidence, the systems affected, a severity rating and clear steps to fix it. Severity is often expressed with a standard scale such as the Common Vulnerability Scoring System (CVSS, currently version 4.0). CVSS measures technical severity, not business risk, so adjust it for the organisation's context, including how exposed and how important the affected system is.
• Attack paths: how individual weaknesses could be combined, which is often the most important insight.
• What went well: defences that worked are worth knowing too.

After the report:

• Prioritise fixes by risk, not by the order in the report.
• Assign owners and dates, and track them like any other work.
• Fix causes, not just symptoms: if the same kind of flaw appears in many places, fix the process that creates it.
• Retest to confirm the fixes work.
• Test regularly, and after significant changes, because systems and attacks change.

Treat reports as sensitive: they are a map of your weaknesses. Share them only with people who need them.

What AI changes

AI is changing penetration testing on both sides.

AI helps testers: - summarising large amounts of reconnaissance data; - suggesting likely weaknesses and next steps based on what has been found; - helping understand unfamiliar code, protocols and configurations; - drafting clear findings and reports; - increasingly, running parts of a test automatically, with tools that chain steps together as an attacker might.

AI raises new questions: - Scope control: an automated or AI-driven tool must stay strictly within the authorised scope. A tool that wanders outside it creates legal and safety problems. - Accuracy: AI can suggest weaknesses that do not exist, or miss ones that do. Findings must be verified by a skilled person before they are reported. - Safety: automated exploitation can disrupt live systems if not tightly controlled. - Data: sending a client's data, code or findings to an outside AI service may breach confidentiality or data protection rules. Sending personal data to an outside AI service is itself processing under data protection law. Agree in advance which tools may be used.

AI systems need testing too. Organisations deploying AI, such as chatbots and AI agents, should include them in testing, looking at risks such as prompt injection, data leakage and excessive permissions.

Used well, AI can make good testers faster and make more frequent testing practical. It does not remove the need for human judgement, clear authorisation and accountable reporting.

Your certificate of completion

Enter your name as you want it to appear, then save the certificate as a PDF. In the print window, choose Save as PDF. A certificate is issued once per completion of the course.

Saolix does not record who takes this course, so it cannot verify these certificates. The certificate confirms completion of a free self-paced course and is not an accredited qualification.