Penetration Testing & Audits

SAST reads source code without running the application, DAST probes a running application from the outside, and IAST watches it from within while it runs. Each sees something different: SAST points at the faulty code, DAST confirms behaviour an attacker can observe, IAST links the two together. A code audit usually combines all three with manual analysis, because tooling alone cannot tell a business logic flaw from an intended feature.

The quote follows the number of tester days needed to walk the scope by hand, not the label on the service. Application count, user roles, critical functions, the mode from black box to white box, and whether testing runs against production or a copy all move that number. Social engineering, out of hours windows and a broad retest add more. Weigh offers on described scope and team composition, since a rate without a scope says nothing.

The schedule for an application test comes from the number of roles, functions and business paths that must be walked manually, not from the size of the interface. On top of the testing window sit scoping, account and environment preparation on your side, and report writing. Experienced teams book ahead, so the start date is often the longer part of the calendar. A retest after fixes is planned separately and covers only the reported findings.

A penetration test can disrupt a live system, so the risk gets negotiated before the start instead of being assumed away. Techniques such as load exhaustion or request floods are usually cut from scope or moved onto a copy of the environment. For everything else the parties fix a testing window, an emergency contact on both sides and a condition for stopping work at once. Operations staff need warning so monitoring alerts do not trigger the incident procedure.

A penetration test needs three roles from the client: a decision maker who signs the scope and the authorisation, a technical system owner, and an emergency contact available during the window. The technical owner prepares accounts at different permission levels, API documentation and access to the environment. When an external hosting company or cloud provider runs the platform, their consent has to be collected first. Once the report lands, developers join, because they ship the fixes.

A penetration test describes one defined scope inside one window of time, not a permanent property of the system. A report without critical findings says only that within that scope, and with the knowledge available, the team found no way in. It is not a certificate, it does not replace an audit against a standard, and it is not red teaming, which also measures whether defenders react. Every later change to code, configuration or libraries opens fresh ground.

The contract has to carry written authorisation with the list of addresses, domains and applications inside scope, because without it the tester's activity is indistinguishable from an attack. It also sets the testing window, the conditions for stopping work, how a critical finding is escalated mid engagement and when the report is delivered. Rights to the report are handled separately, including the right to show it to a customer or an assessor, plus liability limits.

Everything collected during the test, including screenshots, sample records and captured credentials, is confidential material whose handling is agreed before the work starts. Good practice covers a confidentiality agreement, an encrypted channel for the report, a limited recipient list on the provider side and a declared point at which working copies are destroyed. Where personal data sits in scope, a lawful basis and a processing agreement under GDPR are required. Many teams work on masked data or dedicated test accounts.

The deliverable is a report with an executive summary, findings ranked by risk, proof of exploitation and a remediation note for every entry. Findings move into a task tracker with an owner and a due date, instead of staying inside a PDF. Once fixes ship, the retest produces written confirmation that the attack paths are closed. The report and that confirmation then serve as evidence for customers, assessors and insurers.

The rhythm comes from changes in the system and from the obligations the organisation carries, not from the calendar alone. An application shipped in short releases gets a test when architecture, permissions or payments change substantially, with automated scanning and code review in between. Compliance programmes such as PCI DSS or ISO/IEC 27001 expect a regular cycle plus a repeat after any significant change. Changing hosting, migrating to cloud or inheriting a system also warrants a fresh test.