- Service
- Security Testing
Find the weaknesses before someone else does.Penetration testing, code review, and security audits.
Penetration testing, code review, and infrastructure checks for teams that need to know where their systems actually stand — with a report they can act on.
Testing is carried out only with the owner's written authorisation and an agreed scope.
- Built for
- Web apps · Code · Infrastructure
- You receive
- A report you can act on
- Delivered by
- PACSAL
What We Test
Four ways to look at your security.
Take one on its own, or combine them for a fuller picture of a system.
Web application & website testing
Testing a live application the way an attacker would approach it: authentication, access control, input handling, session management, and business logic.
Source code security review
Reading the code itself to find issues that black-box testing misses — unsafe patterns, weak validation, secrets in the repository, and risky dependencies.
Network & infrastructure testing
Examining servers, services, and cloud configuration: exposed services, weak configuration, patch levels, and access paths between systems.
Security audit & hardening report
A review of how a system is built and run, with prioritised hardening steps. No exploitation, so it suits production systems that cannot be disrupted.
What You Get
A report your developers can work from.
Every finding, ranked
Each issue rated by severity, so the important work is obvious.
Steps to reproduce
Exactly how the issue was found, so your team can see it for themselves.
A practical fix
What to change, written for the people who will change it.
A plain summary
A short overview for people who will not read the technical detail.
How It Works
Scope, test, report, retest.
Clear boundaries before anything starts, and a conversation about the findings afterwards.
- 01
Scope
Agree what is in scope, what is off limits, and when testing runs.
- 02
Authorise
Written authorisation from the system owner before any testing begins.
- 03
Test
Hands-on testing, supported by tooling where it helps.
- 04
Report
Findings, severity, reproduction steps, and fixes — walked through with your team.
- 05
Retest
Once fixes are in, the same issues are checked again to confirm they are closed.
Questions
Common questions.
Do you need permission before testing?
Yes. PACSAL tests only with written authorisation from the system's owner, against a scope agreed in advance. Nothing outside that scope is touched.
Will testing break or slow down our live system?
Testing windows and limits are agreed during scoping. If a system cannot tolerate active testing, the security audit and hardening review covers it without exploitation.
Who is the report written for?
Both audiences. Each finding carries severity, reproduction steps, and a practical fix for the engineers, plus a short summary for people who need the overall picture.
What happens after we fix the findings?
The same issues are retested to confirm they are actually closed.
Can you review our source code as well as the running system?
Yes. A source code security review finds issues that testing from the outside cannot see, such as unsafe patterns, weak validation, secrets in the repository, and risky dependencies.
Do you build security tooling too?
Yes. PACSAL built CyberTool.dev, a developer-focused platform for repository scanning and structured findings, and the same engineering approach informs this work.
Start a Security Test
Want to know where your systems stand?
Tell PACSAL what you run and what worries you. We will reply with a scope and next steps.