Cybersecurity
Penetration testing
A penetration test answers a specific question: starting from a defined position, what can an attacker actually do? We test manually, chain weaknesses together, and report what matters in language both executives and engineers can use.
Why scanning is not testing
Automated scanners report known issues. They cannot tell you that a low-severity information leak plus a weak password reset plus an over-permissive internal role add up to full access to customer records.
A penetration test fills that gap. A specialist reads how your system works, forms a theory of how it could be abused, tries it, and records exactly what happened. The result is evidence, not a score.
Who asks for it
-
Security leaders
Evidence for the board and for budget decisions, with realistic attack paths.
-
Engineering leaders
Findings written so developers can reproduce and fix them without a meeting.
-
Compliance and procurement
A report you can hand to a customer or auditor that explains scope, method and limits.
What is in scope
Scope is agreed in writing before testing starts. A typical engagement draws from the list below.
-
External network
Internet-facing hosts and services, exposed management interfaces, VPN and remote access, mail and DNS posture.
-
Internal network
Assumed-breach testing from a workstation or network drop: segmentation, credential exposure, lateral movement.
-
Web applications and APIs
Authentication, session handling, authorization, input handling, file handling and business logic.
-
Cloud environments
AWS, Azure and Google Cloud identity paths, storage, network exposure and pipeline secrets.
-
Active Directory and Entra ID
Attack paths to privileged access, delegation, certificate services, conditional access gaps.
-
Mobile and thick clients
Local storage, transport security, binary protections and the back-end API.
How the work runs
The same phases apply to every engagement. The depth of each changes with scope and approach.
Plan
Agree boundaries and how we will work together.
-
1
Scoping call
Targets, goals, exclusions, environments, test windows and what would count as a successful test.
-
2
Rules of engagement
Written authorization, safe-testing limits, contacts, escalation path and a way to stop immediately.
-
3
Access
Test accounts, VPN or network access, documentation and, for white-box work, code or architecture material.
Test
Hands-on work against agreed targets.
-
4
Reconnaissance and mapping
Identify hosts, endpoints, technologies, trust relationships and entry points within scope.
-
5
Vulnerability analysis
Tool-assisted discovery followed by manual analysis to separate real issues from noise.
-
6
Exploitation
Attempt exploitation within the rules of engagement and chain findings to demonstrate impact.
-
7
Post-exploitation (if in scope)
Show what an attacker could reach next: data, privileges, other systems.
Report
Make the result usable.
-
8
Validation
Re-verify every finding and capture evidence. Anything we cannot reproduce is not reported as confirmed.
-
9
Report and debrief
Written report, then a call with your engineers to walk through the findings and answer questions.
-
10
Retest
After fixes, confirm each finding is closed, partially fixed or still open.
What you receive
- Executive summary in plain language
- Technical findings with evidence and reproduction steps
- Severity rationale tied to impact and exploitability
- Remediation guidance for each finding
- Attack path narrative where findings chain together
- Debrief session with your team
- Retest results finding by finding
- Methodology and scope statement you can give an auditor
Tooling and technique
Tool categories describe how we work. They are not a claim of vendor partnership or certification.
Standards we map to
Mapping findings to a framework is not the same as certification against it.
Before we start
What we need from you
- A named technical contact during the test window
- Written authorization from an owner of the systems
- Test accounts for each role in scope
- Any third-party hosting terms we should check
- A freeze on risky changes during testing, if possible
What this service is not
- A compliance certification
- A guarantee that you cannot be breached
- A substitute for patching and monitoring
- A denial-of-service test, unless scoped separately
What changes afterwards
- You know which findings are exploitable and which are theoretical
- Developers have enough detail to fix without guessing
- Leadership has a short, honest summary of risk
- A retest confirms fixes rather than relying on tickets being closed
What it looks like in practice
Illustrative scenario. Not a real client engagement. No outcomes are claimed.
An example of how a gray-box web and internal test can connect findings. This is an illustrative scenario, not a client case.
- The entry point
- A customer portal lets any logged-in user request an invoice by ID. The ID is a sequential number and the server does not check ownership.
- The chain
- Invoices include an internal support email. That address is a valid sign-in on a help desk system that has no multi-factor authentication.
- The impact
- The help desk lets agents view and reset accounts. A normal customer can reach administrative actions on other customers’ accounts.
- The fix
- Enforce object-level authorization on invoices, require multi-factor authentication on the help desk, and restrict the reset function by role.
Questions people ask
How often should we test?
At least annually for important systems, and after major architecture or release changes. Applications that ship weekly benefit from smaller, targeted tests more often.
Will you test our production environment?
If it is the realistic target, yes, using agreed safe-testing limits. We avoid destructive actions and tell you before anything risky. Some organizations prefer a production-like staging environment, which we also support.
What is the difference between severity and risk?
Severity describes how bad a flaw is in general. Risk includes how easy it is to reach in your environment and what it exposes. We explain both, so you do not have to rank by score alone.
Do you provide a letter of attestation?
We can provide a summary letter stating scope, dates and method for customers who ask. It states what was tested. It is not a statement that the system is secure.
Related
-
Web application penetration testing
Manual testing of authentication, authorization, session handling, input handling and business logic in web applications.
-
Network penetration testing
External and internal network testing: exposed services, weak authentication, segmentation gaps and lateral movement paths.
-
Sample penetration test report
A complete, invented example of a web and API penetration test report: summary, scope, method, findings with evidence, fixes and retest.
-
Remediation and validation
Help engineers fix what was found, then retest to confirm each finding is closed. Fixed, partially fixed or still open.
Need to understand your security exposure?
Speak with a security expert
Talk through your environment and goals. We reply to scope the work before anything is tested.
Speak with a security expertPlan an assessment
Answer a few questions and get a structured preliminary scope you can send us.
Use the plannerUnder attack right now?
Call the US office and tell us what you are seeing. Do not wait for a form reply.
Incident response