- Home
- Services
- Assess & Understand Risk
- Penetration Testing
Know What an Attacker Would Find Before They Do
Security controls can look effective on paper. Penetration testing shows what happens when they are tested from an attacker’s perspective.
Cyber Resilience simulates realistic cyberattacks against networks, applications and systems to identify exploitable weaknesses, validate whether controls hold under pressure, and give your team clear priorities for remediation.
Quick answer
What is penetration testing?
A penetration test is an authorised security assessment that combines technical discovery with manual testing and exploitation to determine whether weaknesses in a defined environment can actually be used by an attacker. Unlike a vulnerability scan, which identifies known issues, penetration testing is designed to show what an attacker could achieve, how weaknesses can be chained, and which findings create the greatest practical exposure.
Why test
Controls should be tested, not assumed.
Real-world testing converts security assumptions into evidence. It helps answer practical questions: Can an internet-facing service be exploited? Could initial internal access lead to wider compromise? Can application controls be bypassed? Could multiple smaller weaknesses be chained into a more serious attack path?
The purpose is not to attack systems for the sake of it. It is to find and prioritise weaknesses before a malicious actor does.
Types of testing
Test the parts of the environment that matter.
- 01
External Network Penetration Testing
Assesses perimeter controls and internet-facing assets such as web and mail services; typically approached from a black-box perspective.
- 02
Internal Network Penetration Testing
Assesses what an attacker could achieve after gaining initial internal access; typically uses a grey-box approach.
- 03
Web Application Penetration Testing
Tests application vulnerabilities such as injection, cross-site scripting, application logic weaknesses and session-management flaws.
- 04
Breach Testing
Broader simulated breach activity that can combine technical testing with physical-access attempts, Wi-Fi assessment and social engineering where explicitly scoped.
- 05
Source Code Reviews
Examines software code for security vulnerabilities, insecure coding practices and potential exploits.
- 06
Attack Simulations
Tests how defences and response capabilities perform against realistic attack scenarios.
Testing approaches
Black box, white box or grey box?
Three testing approaches are used. The right one depends on what the organisation needs the test to prove.
| Approach | What it means | Best suited to |
|---|---|---|
| Black box | The tester starts without prior knowledge of the environment and attempts to identify and exploit weaknesses from an external-attacker perspective. | Testing what a real external attacker may discover and achieve. |
| White box | The tester receives full knowledge or access, potentially including architecture, credentials or source code, enabling deeper targeted testing. | Detailed assessment of defined systems, components or application functionality. |
| Grey box | The tester has partial knowledge or access and combines automated discovery with manual testing. | Testing what an attacker could achieve after obtaining some level of legitimate or initial access. |
How we work
Structured testing. Controlled execution. Clear evidence.
Our testing is aligned to the OWASP Penetration Testing Execution Standard (PTES). Scope, approach and potentially disruptive activities are agreed before testing begins.
- 01
Scope & Rules of Engagement
Define systems, applications, IP ranges, access levels, exclusions, testing approach and operational constraints.
- 02
Discovery
Identify relevant assets, services, technologies and potential attack paths within the authorised scope.
- 03
Vulnerability Analysis
Assess the environment for weaknesses and identify findings that warrant deeper validation.
- 04
Manual Exploitation & Validation
Where authorised, test whether weaknesses can actually be exploited and whether multiple findings can be chained.
- 05
Risk Prioritisation & Reporting
Translate technical findings into severity, practical exposure, evidence and remediation priorities.
- 06
Remediation & Retest
Provide actionable recommendations and, where included in scope, retest findings to verify that remediation has closed the identified exposure.
What you receive
Evidence your technical team can act on — and leadership can understand.
- Executive summaryA leadership-level view of overall results and areas requiring attention.
- Risk assessment matrixPrioritised security risks categorised by severity.
- Comprehensive test reportDetailed findings, vulnerabilities and evidence from the authorised testing.
- Compromise evidence where applicableSuch as accounts, systems or data accessed during the test.
- Actionable recommendationsTechnical patches, configuration changes, account-level fixes and other remediation actions.
- Retest report where included in scopeVerification that remediation has addressed identified findings.
When to test
When should you consider penetration testing?
- You need independent validation that security controls actually work
- A new application, platform or major infrastructure change is going live
- An audit, customer, insurer or regulatory process requires evidence of technical testing
- Internet-facing systems or applications have materially changed
- You need to test the impact of an assumed internal foothold
- A previous vulnerability assessment identified weaknesses that require exploitation validation
- Security leadership needs evidence to prioritise remediation
- You want to move from annual point-in-time testing toward a rolling assurance programme
Penetration test vs vulnerability assessment
A scan finds weaknesses. A penetration test shows what can be done with them.
A vulnerability assessment is designed to identify known weaknesses across a defined environment. A penetration test goes further by combining discovery with manual validation and authorised exploitation to understand whether weaknesses can actually be used, chained, or turned into meaningful compromise.
| Vulnerability Assessment | Penetration Testing |
|---|---|
| Focuses on identifying and prioritising vulnerabilities | Focuses on validating exploitability and attack paths |
| Often uses automated scanning as a major input | Combines discovery with experienced manual testing |
| Provides breadth across known weaknesses | Provides deeper adversarial validation within a defined scope |
| Answers: What weaknesses exist? | Answers: What could an attacker actually achieve? |
Why Cyber Resilience
Testing shaped by an attacker mindset — and forensic experience.
Our testing is built around realistic attack simulation and evidence. The wider business grew out of digital forensics, giving the team a useful perspective on how technical weaknesses become incidents and what evidence matters after compromise.
- 01
Realistic adversarial testing
Rather than reliance on automated scanning alone.
- 02
Approach matched to the question
Black-, white- and grey-box approaches selected around the question the test must answer.
- 03
Executive and technical reporting
Executive reporting alongside detailed technical findings.
- 04
Actionable remediation guidance
Practical next steps, not a list of problems without direction.
- 05
Connected services
Ability to connect testing findings into wider risk assessment, managed security and forensic services.
- 06
Planned around your constraints
Testing planned around scope and operational constraints to minimise unnecessary disruption.
Methodologies & standards
Testing aligned to recognised security methodologies.
Our testing draws on recognised methodologies and standards, including:
- OWASP Penetration Testing Execution Standard (PTES)
- OWASP Top 10
- OWASP API Security Top 10
- MITRE ATT&CK
- NIST SP 800-115
- CREST methodology
Related services
Testing is one part of the assurance picture.
Insights
Continue exploring security testing.
- Security Testing & Assurance
- Cyber Resilience Strategy
- Cyber Risk & Governance
- Cyber Risk & Governance
FAQ
Penetration Testing FAQs
What is the difference between a vulnerability scan and a penetration test?
A vulnerability scan identifies known issues using automated tools. Penetration testing combines discovery with manual validation and authorised exploitation to determine what an attacker could actually achieve, including chained weaknesses and business-logic flaws that automated scanning can miss.
What is the difference between black box, white box and grey box penetration testing?
Black-box testing starts with no internal knowledge and most closely simulates an external attacker. White-box testing uses full knowledge or access for deeper targeted testing. Grey-box testing uses partial knowledge or access and combines elements of both.
Will penetration testing affect our production systems?
Testing is designed to be non-disruptive. Where active exploitation could affect availability, those steps are agreed in advance and can be aligned to maintenance windows.
How often should we run a penetration test?
We recommend testing at least annually, after significant changes to architecture or applications, and where required by relevant frameworks or sector requirements. Some organisations use a rolling programme with different scopes throughout the year.
Do you test web applications?
Yes. Our web application penetration testing covers areas such as injection, cross-site scripting, application logic and session-management weaknesses.
Do you offer internal and external penetration testing?
Yes. Our security-testing scope includes both external network penetration testing and internal network penetration testing.
Do you do social engineering or physical security testing?
These activities fall under Breach Testing, where technical testing can be combined with physical-access attempts, Wi-Fi assessment and social engineering. They require explicit scope and rules of engagement.
Can you retest after we remediate the findings?
Yes, where retesting is included in scope. The deliverables include a retest report that verifies whether remediation has closed the identified findings.
Do you operate outside South Africa?
Our team works across multiple African markets. Jurisdictions, scope and legal authorisations are confirmed during scoping.
Test your controls before someone else does.
Walk us through the systems you need tested, the questions you need answered and the environment you are working with. We will help define the appropriate scope and testing approach.
Speak to the Team