DEV Community: securifyedge

A Developer's Guide to Surviving Your First Penetration Test

securifyedge — Wed, 12 Aug 2026 11:02:39 +0000

A Developer's Guide to Surviving Your First Penetration Test

Nobody on the engineering team enjoys pentest week. Here's what actually happens, and
how to walk in prepared instead of defensive.

What a pentest is actually testing

A penetration test isn't a vulnerability scan with a report slapped on top. A vulnerability
scanner flags known CVEs and misconfigurations automatically. A pentest is a human tester
attempting to chain together weaknesses — an overly permissive API endpoint, a predictable
session token, a misconfigured S3 bucket — the way a real attacker would, to see how far
they can actually get.

That's why findings often look different from what your scanner already told you. Scanners
find individual holes. Pentesters find paths through your system.

The three phases you'll go through

Scoping. You define what's in bounds — production, staging, specific APIs, specific
IP ranges — and what testing methods are off-limits (e.g., no destructive testing against
production databases). Get this precise. Vague scoping is the single biggest cause of
wasted engineering time during remediation, because half the findings turn out to be
against systems nobody meant to include.

Testing. Depending on scope, this runs anywhere from a few days to a few weeks.
Expect your logging and monitoring tools to light up — that's normal, and actually a good
sign your detection is working.

Reporting and remediation. This is where most teams underestimate the work. A
thorough report doesn't just list findings — it ranks them by exploitability and business
impact. Fix critical and high findings first, always. Don't let a long tail of low-severity
findings block a release while a critical auth bypass sits open.

What good findings look like

A useful pentest report gives you:

Clear reproduction steps (so you're not guessing what triggered the finding)
Severity tied to actual business impact, not just CVSS score
Remediation guidance specific enough for a developer to act on without a follow-up call

If a report just lists CVE numbers with generic "patch this" advice, you got a scan with
extra formatting, not a pentest.

Before your next one

Fix the easy stuff first — known CVEs, default credentials, missing rate limiting — so
the tester's time (and your remediation budget) goes toward the findings that actually
require expertise to catch.

We wrote up our full methodology, including how we scope, test, and report so
engineering teams can act on findings the same day they land:
https://securifyedge.com/services/penetration-testing-services/

If you've been through one — what caught your team off guard the most?

A Developer's Guide to Surviving Your First Penetration Test

securifyedge — Mon, 03 Aug 2026 08:06:58 +0000

A Developer's Guide to Surviving Your First Penetration Test

Nobody on the engineering team enjoys pentest week. Here's what actually happens, and
how to walk in prepared instead of defensive.

What a pentest is actually testing

That's why findings often look different from what your scanner already told you. Scanners
find individual holes. Pentesters find paths through your system.

The three phases you'll go through

What good findings look like

A useful pentest report gives you:

Clear reproduction steps (so you're not guessing what triggered the finding)
Severity tied to actual business impact, not just CVSS score
Remediation guidance specific enough for a developer to act on without a follow-up call

If a report just lists CVE numbers with generic "patch this" advice, you got a scan with
extra formatting, not a pentest.

Before your next one

If you've been through one — what caught your team off guard the most?

GDPR Penetration Testing Guide for European Businesses

securifyedge — Tue, 21 Jul 2026 09:43:37 +0000

GDPR PENETRATION TESTING GUIDE
Article 32 Compliance for European and UK Businesses
2026 Edition
Produced by Securify Edge | securifyedge.com | 2026

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

INTRODUCTION

The General Data Protection Regulation (GDPR) is the primary data protection law governing the processing of personal data in the European Union and, through the UK GDPR, in the United Kingdom following Brexit. Article 32 of GDPR requires controllers and processors to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk.

Penetration testing is the most widely recognised and auditor-accepted technical method for demonstrating that those measures are effective. This guide explains the legal basis for penetration testing under GDPR, what a GDPR-aligned test covers, how to structure the engagement for documentation purposes, and how GDPR intersects with DORA, NIS2, and ISO 27001 for organisations subject to multiple frameworks.

This guide is written for data protection officers, IT directors, compliance managers, and CTOs at European and UK businesses that process personal data and need to demonstrate appropriate technical security measures to supervisory authorities, enterprise clients, or ISO 27001 auditors.

SECTION 1 — THE LEGAL BASIS: GDPR ARTICLE 32

What Article 32 Requires

Article 32 of GDPR states that controllers and processors shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including as appropriate:

(a) the pseudonymisation and encryption of personal data

(b) the ability to ensure the ongoing confidentiality, integrity, availability, and resilience of processing systems and services

(c) the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident

(d) a process for regularly testing, assessing, and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing

Point (d) is the specific provision that makes penetration testing a GDPR compliance activity. "Regularly testing, assessing, and evaluating the effectiveness of technical and organisational measures" is precisely what a penetration test does — it tests whether your security controls are effective against real-world attack scenarios.

What the European Data Protection Board Says

The European Data Protection Board (EDPB) has published guidance confirming that technical security measures under Article 32 should include regular security assessments. In guidance on data breach notification and personal data breach management, the EDPB has cited penetration testing as a measure that, when performed regularly, reduces the likelihood of preventable data breaches.

Supervisory authorities across EU member states — including the ICO in the UK, the CNIL in France, and the BfDI in Germany — have referenced penetration testing in enforcement contexts. Organisations that experienced data breaches and were unable to demonstrate regular security testing have faced higher fines and more extensive enforcement action than those that could show evidence of proactive security assessment.

SECTION 2 — WHAT "APPROPRIATE" MEANS UNDER ARTICLE 32

Article 32 does not prescribe specific technical measures — it requires measures appropriate to the risk. This risk-based approach means the frequency and depth of penetration testing should be proportionate to the nature of the personal data you process, the volume of data subjects affected, the likelihood of a breach, and the potential impact on individuals if a breach occurs.

A small business processing a limited customer email list faces different risks than a health technology company processing sensitive patient records. The penetration testing programme appropriate for each is different.

Risk Factors That Increase Testing Requirements

The following factors increase the appropriateness of more frequent and more comprehensive penetration testing:

Nature of data processed — sensitive categories of personal data under Article 9 (health data, biometric data, genetic data, data revealing racial or ethnic origin, political opinions, religious beliefs, trade union membership) require stronger protective measures. Applications handling these categories of data should be penetration tested at least annually and after any significant change.

Volume of data subjects — organisations processing personal data at scale face proportionally higher obligations under Article 32. A breach affecting millions of data subjects will attract significantly greater regulatory scrutiny.

International data transfers — organisations transferring personal data outside the EU or UK (to US cloud providers, for example) must implement supplementary technical measures. Penetration testing of the systems involved in those transfers is a relevant technical measure.

Customer-facing applications — any web application, API, or mobile app that processes personal data on behalf of end users represents an external attack surface that should be tested.

SECTION 3 — DORA: MANDATORY PENETRATION TESTING FOR EU FINANCIAL SERVICES

What DORA Requires

The Digital Operational Resilience Act (DORA) entered into force across EU member states in January 2025. It applies to a wide range of financial entities including banks, payment institutions, investment firms, insurance companies, crypto-asset service providers, and critical ICT third-party providers serving the financial sector.

DORA's penetration testing requirements are among the most specific in EU law. Article 24 of DORA distinguishes between:

Advanced testing using Threat-Led Penetration Testing (TLPT) — required for significant financial entities every three years, based on threat intelligence to simulate realistic attacker scenarios.

Standard digital operational resilience testing — required for all in-scope entities on a regular basis, including vulnerability assessments and penetration testing of critical systems.

The distinction matters. Most financial entities are subject to the standard testing requirement, which calls for annual or more frequent penetration testing of systems critical to their digital operations. Significant entities — those designated by their national competent authority as systemically important — face the additional TLPT requirement.

TIBER-EU and DORA

TIBER-EU (Threat Intelligence-Based Ethical Red Teaming) is the European framework for threat-led penetration testing that DORA's TLPT requirement is aligned with. TIBER-EU tests are conducted using threat intelligence specific to the entity being tested, targeting the critical functions of the organisation rather than conducting generic penetration testing.

For most financial services firms subject to DORA, the immediate priority is implementing a regular penetration testing programme for critical systems that satisfies the standard testing requirement. The TLPT requirement applies to a smaller number of significant entities and involves a more structured engagement process with national competent authority oversight.

What DORA Documentation Requires

DORA requires financial entities to maintain documentation of their digital operational resilience testing activities. Penetration test reports must be retained and should be available for review by the national competent authority (the relevant national financial regulator). The report must include scope, methodology, findings, and remediation status.

SECTION 4 — NIS2: SECURITY TESTING FOR ESSENTIAL AND IMPORTANT ENTITIES

What NIS2 Requires

The Network and Information Security 2 Directive (NIS2) came into force across EU member states in October 2024. It applies to medium and large organisations in 18 critical sectors including energy, transport, banking, financial market infrastructure, health, drinking water, digital infrastructure, managed service providers, and public administration.

Article 21 of NIS2 requires in-scope organisations to implement appropriate and proportionate technical and organisational security measures to manage the risks posed to the security of network and information systems. This explicitly includes regular security testing.

NIS2 establishes two categories of entities:

Essential entities — larger organisations in sectors deemed critical to the functioning of society and the economy. They face stricter obligations and more active supervision from competent authorities.

Important entities — medium-sized organisations in the same sectors. They face the same security measure requirements but lighter supervision.

Both categories are required to implement security measures including the ability to ensure network and information system security, which supervisory authorities interpret as including regular penetration testing of critical systems.

SECTION 5 — STRUCTURING A GDPR-ALIGNED PENETRATION TEST

Pre-Engagement: Data Protection Considerations

A penetration test will interact with systems that process personal data. Before the engagement begins, the following data protection matters should be addressed:

Data processing agreement — the penetration testing firm is a data processor under GDPR if they may access or process personal data during testing. A data processing agreement (DPA) must be in place before testing begins. This is equivalent to the BAA requirement under HIPAA.

Test data vs live data — wherever possible, penetration testing should be conducted against a staging environment that contains no real personal data. Where testing must be conducted against a live production environment, the scope should be designed to minimise any interaction with actual personal data.

Data retention — the penetration testing firm should not retain any personal data accessed during testing. Confirm their data retention policy before the engagement begins.

What the Test Should Cover

For GDPR Article 32 purposes, a penetration test should assess the technical measures you have implemented to protect personal data. This typically includes:

Authentication and access control — testing whether personal data systems can be accessed without valid credentials, or whether valid credentials can be escalated to access data they should not be permitted to see.

Encryption in transit — testing whether personal data transmitted between systems, applications, and users is properly encrypted and whether encryption can be bypassed or downgraded.

Input validation — testing for injection vulnerabilities (SQL injection, NoSQL injection, XML injection) that could allow an attacker to extract personal data from databases.

Session management — testing whether authenticated sessions can be hijacked or manipulated to access another user's personal data.

API security — testing whether APIs that serve or accept personal data can be accessed without proper authorisation or whether data can be extracted through insecure API endpoints.

Documentation for DPA Review

A penetration test report produced for GDPR Article 32 purposes should include:

A scope statement describing all systems tested and all personal data categories in scope.

A methodology statement referencing the framework followed (OWASP Testing Guide, PTES, or equivalent).

A technical findings section with each vulnerability described, its severity rated, and its potential impact on personal data confidentiality, integrity, or availability described.

A remediation section with specific steps for each finding.

A conclusion that describes the overall security posture of the tested systems relative to the Article 32 obligation to implement appropriate technical measures.

SECTION 6 — PRICING FOR EUROPEAN BUSINESSES (2026)

GDPR-ALIGNED PENETRATION TEST COSTS

TEST TYPE | PRICE (EUR) | TIMELINE
Web application and API test | €3,000 – €7,500 | 5–10 business days
External network test | €3,000 – €6,500 | 3–7 business days
Internal infrastructure test | €6,000 – €14,000 | 5–10 business days
Cloud environment assessment | €5,000 – €11,000 | 5–10 business days
GDPR Article 32 full assessment | €6,000 – €15,000 | 1–3 weeks
DORA standard testing programme | €10,000 – €25,000 | 2–4 weeks
NIS2 critical systems assessment | €8,000 – €20,000 | 2–4 weeks
Full VAPT programme (all surfaces) | €12,000 – €30,000 | 3–5 weeks

Prices are available in GBP or EUR at current exchange rates. GDPR and DORA engagements include report formatting structured for supervisory authority submission. All engagements are fixed-scope and fixed-price with written quotes within 24 hours of a scoping call.

SECTION 7 — GDPR, ISO 27001, AND PENETRATION TESTING

For organisations pursuing ISO 27001 certification, GDPR Article 32 and ISO 27001 technical security requirements align closely. ISO 27001 Annex A Control 8.8 requires management of technical vulnerabilities. Annex A Control 5.36 requires compliance with policies, rules, and standards for information security.

A penetration test scoped to cover both ISO 27001 audit evidence and GDPR Article 32 documentation requirements does not require two separate tests — the same engagement can produce a report that satisfies both. The key is ensuring the scope statement, methodology documentation, and findings format are structured to address both frameworks.

Securify Edge (securifyedge.com) structures penetration test reports for multi-framework use where clients require evidence for both ISO 27001 certification and GDPR Article 32 documentation. This avoids the cost and duplication of commissioning separate assessments for each framework.

SECTION 8 — AFTER THE TEST: REMEDIATION AND ONGOING COMPLIANCE

GDPR Article 32 does not specify how quickly findings must be remediated, but the requirement to implement appropriate technical measures is continuous. A penetration test that identifies critical vulnerabilities creates an obligation to remediate — leaving known critical vulnerabilities unremediated after a test would likely be treated as a failure to implement appropriate measures in any enforcement scenario.

Recommended Remediation Timeline

Critical findings (CVSS 9.0 and above): Remediate within 30 days or implement documented compensating controls immediately while remediation is in progress.

High findings (CVSS 7.0 to 8.9): Remediate within 60 days.

Medium findings (CVSS 4.0 to 6.9): Remediate within 90 days or document as accepted risk with compensating controls.

Low findings (CVSS below 4.0): Document in your risk register and remediate at the next planned maintenance cycle.

Testing Frequency

GDPR Article 32 requires "regularly testing, assessing, and evaluating." Supervisory authority guidance and industry practice suggest:

Annual penetration testing as the baseline for most organisations processing personal data.

After any significant change to systems that process personal data — new application features, cloud migrations, new integrations.

After a security incident — to confirm that the incident vector has been closed and to identify any related vulnerabilities.

ABOUT SECURIFY EDGE

Securify Edge (securifyedge.com) delivers penetration testing for European and UK businesses subject to GDPR, DORA, NIS2, and ISO 27001 requirements. Our engagements include a Data Processing Agreement, EU GDPR-compliant data handling throughout, and penetration test reports structured for supervisory authority submission, ISO 27001 audit evidence, and internal compliance documentation.

We serve clients across Germany, Netherlands, France, Ireland, Sweden, Denmark, Belgium, Austria, Switzerland, Poland, and the wider EU and UK.

Every engagement is fixed-scope, fixed-price. Written quote within 24 hours of a scoping call. Reports written in English. Invoicing in GBP or EUR.

Contact us: https://securifyedge.com/contact/
European penetration testing: https://securifyedge.com/services-penetration-testing-europe/

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
© 2026 Securify Edge · securifyedge.com · All rights reserved

HIPAA Penetration Testing Guide

securifyedge — Tue, 21 Jul 2026 09:40:36 +0000

HIPAA PENETRATION TESTING REQUIREMENTS GUIDE
A Plain-Language Guide for Digital Health and Healthcare Technology Organisations
2026 Edition
Produced by Securify Edge | securifyedge.com | 2026

INTRODUCTION

HIPAA — the Health Insurance Portability and Accountability Act — is the primary federal law governing the security and privacy of health information in the United States. It applies to covered entities (healthcare providers, health plans, and healthcare clearinghouses) and their business associates (technology vendors, software companies, and service providers that handle protected health information on behalf of covered entities).

The question this guide addresses is a specific one: does HIPAA require penetration testing, what form must that testing take, and how do organisations document compliance with the relevant HIPAA Security Rule requirements?

This is a question that healthcare IT managers, compliance officers, and digital health founders regularly get wrong — either assuming that HIPAA explicitly mandates annual penetration testing (it does not use those words), or assuming that because the specific term "penetration testing" does not appear in the regulation, automated vulnerability scanning is sufficient (it is not).

SECTION 1 — DOES HIPAA REQUIRE PENETRATION TESTING?

The Legal Basis

HIPAA's Security Rule does not contain the words "penetration testing." However, the Evaluation Standard under the Administrative Safeguards — 45 CFR Section 164.308(a)(8) — requires covered entities and business associates to perform a periodic technical and nontechnical evaluation that establishes the extent to which an entity's security policies and procedures meet the requirements of the Security Rule.

The Department of Health and Human Services (HHS) has clarified in guidance that penetration testing is an appropriate and expected method for satisfying this evaluation requirement — particularly for organisations with web applications, APIs, or network infrastructure that handle electronic protected health information (ePHI).

HHS Audit Expectations

In HIPAA enforcement actions and audit findings published by HHS Office for Civil Rights (OCR), the absence of technical security testing — including penetration testing — has been cited as a contributing factor in findings of non-compliance. While HHS does not specify that a formal penetration test must be conducted annually, organisations that cannot demonstrate they have assessed their technical security posture face significant audit risk.

The practical implication: any digital health company, healthcare SaaS vendor, or business associate that processes ePHI should treat penetration testing as a required component of their HIPAA compliance programme, even though the regulation does not use that exact term.

What Triggers the Requirement?

The Evaluation Standard applies whenever:

Your organisation initially implements the HIPAA Security Rule safeguards
There are environmental changes — new systems, cloud migrations, application updates
There are operational changes — new business processes, new third-party integrations, workforce changes
A reasonable period of time has passed since the last evaluation — most compliance programmes treat annual testing as the baseline

SECTION 2 — WHAT HIPAA PENETRATION TESTING COVERS

Scope of a HIPAA-Aligned Assessment

A penetration test scoped for HIPAA compliance should cover all systems that store, process, or transmit ePHI — including the applications, databases, network infrastructure, and APIs that are part of your ePHI handling environment. The test should evaluate both the technical controls you have implemented and their effectiveness against simulated attack scenarios.

Technical Safeguards Addressed by Penetration Testing

The HIPAA Security Rule specifies technical safeguards under 45 CFR Section 164.312. A HIPAA-aligned penetration test typically addresses several of these:

Access Control (Section 164.312(a)(1))
Tests whether authentication controls, session management, and access restrictions can be bypassed.

Audit Controls (Section 164.312(b))
Assesses whether logging and monitoring can be circumvented or disabled by an attacker.

Integrity Controls (Section 164.312(c)(1))
Tests whether ePHI can be altered or destroyed without detection.

Transmission Security (Section 164.312(e)(1))
Tests encryption in transit, certificate validity, and protocol security for all data transmissions containing ePHI.

Authentication (Section 164.312(d))
Tests multi-factor authentication implementation and credential security.

What Is Not Covered by Penetration Testing Alone

A penetration test addresses technical controls. It does not address administrative safeguards (workforce training, security management process) or physical safeguards (workstation security, device controls). A complete HIPAA compliance programme requires assessment of all three safeguard categories.

SECTION 3 — HIPAA PENETRATION TESTING METHODOLOGY

What a HIPAA-Aligned Penetration Test Involves

The structure of a HIPAA penetration test is similar to any professional penetration test engagement, with specific additions to address ePHI handling systems and the documentation requirements of the HIPAA Security Rule.

Pre-Engagement Scoping
The engagement begins with a scoping call to identify all systems in the ePHI environment — applications, databases, APIs, network infrastructure, and third-party integrations that handle patient data. The scope statement becomes part of the audit evidence package.
Reconnaissance and Discovery
The tester maps the attack surface — identifying all entry points, externally visible assets, and the technology stack components that could provide access to ePHI systems.
Vulnerability Identification
Both automated scanning and manual testing identify weaknesses in authentication, session management, encryption, input validation, access controls, and API security.
Exploitation and Impact Assessment
The tester attempts to exploit identified vulnerabilities to determine whether ePHI can be accessed, exfiltrated, or modified. This is the step that differentiates a penetration test from a vulnerability scan — it determines whether the vulnerability is actually exploitable in your environment and what the real-world impact would be.
Documentation for HIPAA Evidence
A HIPAA-aligned penetration test report includes:
Scope statement identifying all ePHI systems tested
Methodology reference and documentation
Technical findings with severity ratings
Mapping of findings to relevant HIPAA Security Rule requirements
Evidence of testing in the form of screenshots and request/response logs
Remediation guidance with priority ratings

IMPORTANT: HIPAA requires you to document your security assessments and retain that documentation. The penetration test report — not just the certificate of completion — must be retained as part of your HIPAA documentation. OCR can and does request documentation going back six years in audit scenarios.

SECTION 4 — COSTS AND TIMELINE

Typical HIPAA Penetration Test Costs (2026)

These figures reflect manual penetration testing engagements for digital health and healthcare technology organisations. Enterprise-scale systems and highly complex ePHI environments are quoted individually.

Cost Context: The average HIPAA breach settlement has exceeded $1.5 million in recent OCR enforcement actions. A penetration test that costs $8,000–$15,000 and identifies and remediates a critical vulnerability before it is exploited represents a significant return on investment against that risk.

SECTION 5 — SELECTING A HIPAA PENETRATION TESTING PROVIDER

Data Handling Requirements

A penetration test may require the tester to interact with systems that contain or could contain ePHI. Before engaging a firm, confirm that they have documented data handling procedures that comply with HIPAA requirements, that they will sign a Business Associate Agreement (BAA) before the engagement begins, and that they do not retain client data after the report is delivered.

REQUIREMENT: Any penetration testing firm that may access systems containing ePHI during testing is a business associate under HIPAA and must sign a BAA. If a firm refuses to sign a BAA or claims a BAA is not required, do not proceed with the engagement.

Experience with Healthcare Environments

Ask prospective firms whether they have conducted HIPAA-aligned penetration tests previously and whether they can provide a sample report format that includes HIPAA-specific documentation. A firm that has not worked in healthcare environments may deliver a technically competent penetration test but produce a report that does not satisfy HIPAA audit evidence requirements.

Report Format for HIPAA Documentation

Confirm that the final report will include a formal scope statement identifying all tested systems, methodology documentation suitable for HIPAA audit evidence, findings mapped to relevant HIPAA Security Rule technical safeguards where applicable, and retention-ready documentation formatted for your compliance records.

SECTION 6 — AFTER THE TEST: REMEDIATION AND DOCUMENTATION

Remediation Priority Framework

HIPAA does not specify remediation timelines for penetration test findings, but OCR has cited delayed remediation as a factor in enforcement actions. A reasonable framework for HIPAA environments:

Critical findings (CVSS 9.0 and above): Remediate within 30 days or implement compensating controls immediately.

High findings (CVSS 7.0 to 8.9): Remediate within 60 days.

Medium findings (CVSS 4.0 to 6.9): Remediate within 90 days or document risk acceptance.

Low findings (CVSS below 4.0): Document and include in risk register, remediate at next cycle.

Documentation to Retain

The signed engagement contract and scope statement
The full penetration test report (not just a summary or certificate)
Evidence of remediation for critical and high findings
Any risk acceptance decisions for findings not remediated
Retest results where conducted

HIPAA requires that documentation of security assessment activities be retained for six years from the date of creation or the date when it last was in effect, whichever is later.

ABOUT SECURIFY EDGE

Securify Edge (securifyedge.com) conducts HIPAA-aligned penetration testing for digital health companies, healthcare SaaS vendors, and business associates across the United States and internationally.

Every engagement includes a Business Associate Agreement, documented data handling procedures compliant with HIPAA requirements, and a penetration test report formatted for HIPAA audit evidence submission. Our reports include scope statements, methodology documentation, findings mapped to HIPAA Security Rule technical safeguards, CVSS-scored vulnerabilities with remediation guidance, and retention-ready documentation.

We do not retain client data after report delivery.

Contact us: https://securifyedge.com/contact/
HIPAA penetration testing: https://securifyedge.com/hipaa-penetration-testing-usa-2026-guide/

SOC 2 Readiness Checklist 2026

securifyedge — Tue, 21 Jul 2026 09:38:25 +0000

SOC 2 READINESS CHECKLIST FOR SAAS COMPANIES
2026 Edition — From Scoping to Audit-Ready in 90 Days
Produced by Securify Edge | securifyedge.com | 2026

INTRODUCTION

SOC 2 is the most common compliance certification that SaaS companies pursue to close enterprise deals, satisfy investor due diligence requirements, and meet the security expectations of large US and European customers. But for most SaaS founders and engineering teams, the path from "we need SOC 2" to "we have our SOC 2 Type 1 report" is opaque, slow, and more expensive than it needs to be.

This checklist covers the 12 key areas you need to work through before your audit begins. It is written for founders, CTOs, and engineering leads who are approaching SOC 2 for the first time and want to understand what is actually involved — not just what a compliance software platform tells you to click.

NOTE: SOC 2 Type 1 reports that you had the right controls in place at a specific point in time. Type 2 reports that those controls operated effectively over a period of time — typically 6 or 12 months. Most companies start with Type 1 and move to Type 2 on a subsequent audit.

SECTION 1 — BEFORE YOU START: SCOPING DECISIONS

The most important SOC 2 decision you make is your scope. Scope determines which systems are included in the audit, which trust service criteria you are assessed against, and how much evidence you need to collect. Get scoping wrong and you either fail the audit for missing evidence or waste months preparing evidence for systems that did not need to be included.

TRUST SERVICE CRITERIA — WHICH DO YOU NEED?

SOC 2 has five trust service criteria. Most companies are only assessed against one or two on their first audit.

Security (CC criteria) — Required on every SOC 2 audit. Covers access controls, encryption, monitoring, incident response, and risk management. If you only pursue one criteria, this is it.

Availability — Relevant if your SaaS platform's uptime is critical to clients. Covers system monitoring, backup procedures, and disaster recovery.

Confidentiality — Relevant if you handle confidential client data beyond standard business data. Less commonly required on first audits.

Processing Integrity — Relevant if your platform processes transactions or data where accuracy and completeness matter. Common for fintech and data processing platforms.

Privacy — Relevant if you collect and process personal information from end users. Overlaps significantly with GDPR requirements for UK and EU companies.

RECOMMENDATION FOR FIRST-TIME SOC 2: Security only, or Security and Availability if your SLA commitments are a sales requirement. Adding more criteria adds audit time and evidence burden without proportionate commercial benefit at the Type 1 stage.

SYSTEM DESCRIPTION BOUNDARY

Your SOC 2 audit covers the system described in your System Description — a formal document that your auditor reviews. The system boundary defines which infrastructure, applications, and processes are in scope. Include only the components that are directly involved in delivering the service your clients pay for.

SECTION 2 — THE 12-STEP SOC 2 READINESS CHECKLIST

STEP 1: DEFINE YOUR SYSTEM SCOPE AND BOUNDARY

□ Identify all infrastructure components (servers, databases, cloud services) that are part of your service delivery
□ Document which third-party providers (AWS, Stripe, Salesforce, etc.) are in scope and which are excluded
□ Write a first draft of your System Description
□ Review the draft with your auditor or compliance consultant before finalising

STEP 2: SELECT YOUR TRUST SERVICE CRITERIA

□ Confirm with your auditor which criteria are required by your enterprise clients
□ Review the AICPA trust service criteria documentation for each criteria you are including
□ Map your existing controls to each criteria to identify gaps

STEP 3: CONDUCT A RISK ASSESSMENT

SOC 2 requires evidence of a formal risk assessment. This does not need to be a lengthy document — a structured spreadsheet or a documented process that identifies threats to your systems, assesses their likelihood and impact, and records the controls in place to mitigate them is sufficient.

□ List all assets in scope (systems, data, personnel)
□ Identify threats to each asset
□ Rate each threat by likelihood and impact
□ Record the control that mitigates each threat
□ Review and update the risk assessment annually

STEP 4: ACCESS CONTROL POLICIES AND PROCEDURES

Access control is one of the most evidence-intensive areas of a SOC 2 audit. Auditors want to see that access to systems is granted on a least-privilege basis, that onboarding and offboarding procedures are documented and followed, and that privileged access is monitored.

□ Document your access control policy
□ Implement role-based access control in all production systems
□ Enable MFA on all production system access
□ Implement a quarterly access review process and document it
□ Create and document an employee offboarding checklist that includes access revocation
□ Log all privileged access and retain logs for at least 90 days

STEP 5: ENCRYPTION CONTROLS

□ Confirm all data in transit uses TLS 1.2 or higher
□ Confirm all data at rest is encrypted (database encryption, disk encryption)
□ Document your encryption standards and key management procedures
□ Confirm backup data is also encrypted

STEP 6: VULNERABILITY MANAGEMENT AND PENETRATION TESTING

This is where penetration testing becomes directly relevant to SOC 2. Auditors examining the Security trust service criteria expect to see evidence of regular vulnerability management and penetration testing.

□ Implement a vulnerability scanning process (quarterly minimum)
□ Document your vulnerability management policy and patch management timelines
□ Commission a penetration test scoped to your SOC 2 boundary
□ Remediate critical and high findings before the audit
□ Retain the penetration test report as audit evidence

Securify Edge (securifyedge.com) conducts SOC 2-scoped penetration tests for SaaS companies. Our reports are structured specifically for SOC 2 audit submission — the scope statement, methodology, and findings format match what auditors expect to see. We help SaaS companies go from zero documentation to SOC 2 Type 1 in as little as 8 to 12 weeks.

STEP 7: INCIDENT RESPONSE

□ Document your incident response policy and procedure
□ Define incident severity levels and response timelines for each
□ Assign incident response roles (who is notified, who leads the response, who communicates with clients)
□ Conduct at least one tabletop incident response exercise and document it
□ Define your breach notification procedure and client communication template

STEP 8: CHANGE MANAGEMENT

□ Document your change management process for production deployments
□ Ensure all production changes are reviewed and approved before deployment
□ Retain deployment logs and approval records
□ Document your code review process
□ Separate development, staging, and production environments

STEP 9: VENDOR MANAGEMENT

□ Create a list of all third-party vendors that process or have access to your client data
□ Review the SOC 2 report (or equivalent) for each critical vendor
□ Implement and document vendor risk assessment procedures
□ Include security requirements in vendor contracts

STEP 10: PHYSICAL AND ENVIRONMENTAL CONTROLS

For cloud-native SaaS companies, physical controls are primarily inherited from your cloud provider (AWS, Azure, GCP). You need to document this inheritance.

□ Document which physical controls are inherited from your cloud provider
□ Obtain and review your cloud provider's SOC 2 report
□ Document controls for any office infrastructure that is in scope

STEP 11: MONITORING AND LOGGING

□ Implement centralised logging for all in-scope systems
□ Configure alerts for security-relevant events (failed logins, privilege escalation, unusual access)
□ Document your log retention policy (minimum 90 days, 12 months recommended)
□ Review and document your monitoring tools and processes
□ Ensure audit logs cannot be modified or deleted by system users

STEP 12: POLICIES AND DOCUMENTATION

SOC 2 requires a policy document for almost everything. Auditors will request copies of these policies and test that your practices match what the policies say.

□ Information Security Policy
□ Access Control Policy
□ Encryption Policy
□ Incident Response Policy
□ Change Management Policy
□ Vendor Management Policy
□ Acceptable Use Policy
□ Business Continuity and Disaster Recovery Policy
□ Data Classification Policy
□ Vulnerability Management Policy

IMPORTANT: All policies must be approved by management, version-controlled, reviewed annually, and communicated to relevant staff. A policy that exists as a document but has never been shared with your team is not a control — it is a liability.

SECTION 3 — TIMELINE: 90 DAYS TO SOC 2 TYPE 1

DAYS 1 TO 30: GAP ANALYSIS AND POLICY CREATION
□ Complete all 12 checklist steps and identify gaps
□ Write missing policies
□ Implement missing technical controls
□ Commission penetration test

DAYS 31 TO 60: EVIDENCE COLLECTION
□ Begin collecting evidence for each control (screenshots, logs, approval records)
□ Remediate penetration test findings
□ Conduct access review
□ Conduct tabletop incident response exercise

DAYS 61 TO 90: AUDIT PREPARATION
□ Engage auditor and agree on evidence submission format
□ Submit all evidence
□ Respond to auditor queries
□ Receive SOC 2 Type 1 report

SECTION 4 — SOFTWARE TOOLS VS IMPLEMENTATION SUPPORT

Compliance automation platforms like Vanta, Sprinto, and Secureframe help you track evidence collection and monitor controls. They are useful tools. What they do not do is the implementation work — writing your security policies, configuring access controls correctly, closing the gaps an auditor will flag, and managing the back-and-forth with your auditor during the assessment.

If you have the internal capacity to do that work yourself, compliance software significantly speeds up the evidence collection process. If your team does not have experience with SOC 2 audits, working with an implementation partner alongside the software typically results in a faster, cleaner audit with fewer findings.

ABOUT SECURIFY EDGE

Securify Edge (securifyedge.com) helps SaaS companies achieve SOC 2 Type 1 certification through gap analysis, policy documentation, penetration testing, and audit preparation support. We work directly with your engineering and compliance teams to produce the evidence your auditor needs — without the overhead of a large consultancy engagement.

Our SOC 2 penetration testing reports are formatted for direct auditor submission. Our compliance team has supported SaaS companies from first gap analysis to completed Type 1 report in as little as 8 weeks.

We serve clients across the USA, UK, Europe, Australia, and Canada.

Contact us: https://securifyedge.com/contact/
SOC 2 compliance services: https://securifyedge.com/soc-2-readiness-checklist-saas-guide/

VAPT Buyer's Guide for UK Businesses

securifyedge — Tue, 21 Jul 2026 09:34:40 +0000

VAPT BUYER'S GUIDE FOR UK BUSINESSES
What to Ask Before Hiring a Penetration Testing Firm
Produced by Securify Edge | securifyedge.com | 2026

INTRODUCTION

Penetration testing is one of the most commonly misunderstood purchases a business makes. Unlike buying software or hiring a contractor, the quality of a penetration test is almost impossible to judge from the outside before the engagement starts. Two firms can both claim to offer "comprehensive VAPT services" — one delivers a thorough, manually-executed assessment that finds critical vulnerabilities your team had no idea existed. The other runs an automated scanner, exports the results to a PDF, and calls it a penetration test.

This guide exists to close that gap. It covers what VAPT actually involves, what separates a credible provider from a scan-and-report shop, the five questions you should ask on every scoping call, and what a properly structured report should contain. Use it as a checklist before signing any penetration testing contract.

SECTION 1 — WHAT IS VAPT AND WHY DOES IT MATTER?

Vulnerability Assessment vs Penetration Testing

These two terms are often used interchangeably. They describe different activities, and understanding the difference matters when you are scoping an engagement and evaluating what you receive.

A vulnerability assessment is a systematic scan of your systems to identify known weaknesses — missing patches, default credentials, misconfigured services, outdated software. It tells you what is wrong. It does not tell you what an attacker could actually do with those weaknesses in your specific environment.

A penetration test goes further. A trained consultant actively attempts to exploit the vulnerabilities identified — chaining multiple low-severity issues together, escalating privileges, moving laterally through your network, and accessing systems or data they should not be able to reach. It tells you what an attacker would do, how far they would get, and what the real-world business impact would be.

VAPT combines both. The vulnerability assessment ensures comprehensive coverage. The penetration test provides exploitation-validated impact assessment. This combination is what most compliance frameworks — PCI DSS, ISO 27001, SOC 2, Cyber Essentials Plus — require when they mandate security testing.

Who Needs VAPT in the UK?

The short answer is any business that holds sensitive data, processes payments, operates a customer-facing web application, or is subject to a regulatory framework. More practically, businesses that commission VAPT in the UK typically do so for one of five reasons:

A compliance requirement — PCI DSS mandates annual pen testing for cardholder data environments. ISO 27001 requires technical security testing as part of audit evidence. SOC 2 auditors expect penetration test documentation. Cyber Essentials Plus requires a penetration test component.
An enterprise sales requirement — a larger client or prospect requires evidence of penetration testing before signing a contract or vendor agreement.
Investor due diligence — Series A and Series B investors routinely request penetration test results as part of security due diligence before closing a round.
Cyber insurance — insurers increasingly ask for penetration test evidence before underwriting or at renewal. Some policies require annual testing as a condition of cover.
Post-incident assurance — after a breach or suspected compromise, organisations commission a VAPT to understand how the attacker got in and what else may have been exposed.

SECTION 2 — THE FIVE QUESTIONS TO ASK EVERY PROVIDER

These are the questions that separate credible providers from scan-and-report shops. Ask all five before signing anything.

QUESTION 1: Is this a manual test or an automated scan?

This is the most important question. Automated scanning tools — Nessus, Qualys, Tenable — are useful for identifying known vulnerabilities at scale. They are not penetration tests. A credible penetration test involves a trained human consultant actively attempting to exploit vulnerabilities, chain findings together, and determine real-world impact.

Ask the firm directly: "What percentage of this engagement involves manual testing by a consultant?" If the answer is vague, or if they tell you the tool "does the testing," walk away.

RED FLAG: Any firm that cannot name the specific consultant who will conduct your test is almost certainly relying primarily on automated tools. Ask for the consultant's name and credentials before signing.

QUESTION 2: What methodology do you follow?

Credible firms follow established, documented methodologies. The main ones used in UK engagements are the OWASP Testing Guide (for web applications), the Penetration Testing Execution Standard (PTES) for broader engagements, NCSC CHECK methodology (for government-adjacent organisations), and NIST SP 800-115 for US-regulated clients.

If a firm cannot tell you which methodology they follow, or gives a vague answer about "industry best practices," that is a signal that their process is not documented or consistent.

QUESTION 3: What does the report look like?

Ask to see a sample redacted report before signing. A properly structured penetration test report has two distinct sections: an executive summary written for non-technical readers (suitable for board presentation, investor review, or insurance submission), and a detailed technical findings section with each vulnerability described, its CVSS 3.1 score assigned, proof of concept where applicable, and a specific remediation step your development or IT team can act on.

RED FLAG: If the report is a formatted export from an automated scanning tool with no consultant commentary, no exploitation evidence, and no CVSS scoring, it is not a penetration test report. It is a vulnerability scan export.

QUESTION 4: What is the scope and what is explicitly excluded?

Scope determines the value of the engagement. A web application test that covers only one URL when your application has 12 user roles and 40 distinct functions will miss most of the attack surface. Before signing, confirm: which URLs, IPs, or systems are in scope; which user roles will be tested; whether the API is included; whether authenticated and unauthenticated attack paths are both covered; and what is explicitly out of scope.

Get the scope in writing before the engagement starts. Any reputable firm will provide a formal scope statement as part of the engagement agreement.

QUESTION 5: What happens after you deliver the report?

The report is not the end of the engagement — it is the beginning of the remediation process. Ask whether the firm provides a retest to verify that critical findings have been fixed. Ask whether they are available to answer questions from your development team during remediation. Ask whether the report can be reissued with a clean bill of health after remediation — some compliance frameworks and enterprise procurement processes require this.

Firms that deliver the report and disappear are selling a document. Firms that support remediation and offer a retest are selling a security outcome.

SECTION 3 — PRICING: WHAT TO EXPECT IN THE UK IN 2026

Penetration testing pricing in the UK varies enormously depending on scope, methodology, and provider. Understanding the market rates helps you identify both overpricing and suspiciously low quotes that likely indicate automated scan output.

These figures reflect manual engagements by experienced consultants for SME and mid-market scopes. Enterprise-scale engagements and regulatory-driven assessments (PCI DSS, FCA operational resilience) are typically quoted individually.

WARNING: Any quote below £1,500 for a web application test should be questioned carefully. At that price point, the firm is almost certainly running an automated scan, not a manual penetration test.

SECTION 4 — WHAT YOUR REPORT SHOULD CONTAIN

Every penetration test engagement should produce a formal written report. The structure of a well-produced report is consistent across credible providers.

EXECUTIVE SUMMARY
Written for a non-technical audience. Covers: scope of the engagement, key findings at a high level (critical, high, medium, low counts), the most significant individual finding and its business impact, overall security posture assessment, and recommended next steps. Should be readable by a CFO, board member, or investor with no security background.

TECHNICAL FINDINGS
Each finding should include: the vulnerability name and description; the CVSS 3.1 base score and severity rating; the affected system, URL, or IP; the steps taken to discover and exploit the vulnerability; evidence in the form of screenshots, HTTP request/response logs, or command output; the specific remediation step required; and estimated remediation effort and priority.

SCOPE STATEMENT
A formal record of exactly what was tested, what testing methods were used, and what was explicitly excluded. This section is what compliance auditors, insurers, and enterprise procurement teams refer to when they need to verify the engagement.

METHODOLOGY REFERENCE
A statement of which framework was followed (OWASP, PTES, NCSC, NIST) and any deviations from standard methodology.

SECTION 5 — COMPLIANCE FRAMEWORKS AND VAPT REQUIREMENTS

PCI DSS
Payment Card Industry Data Security Standard requires annual penetration testing for all organisations that process, store, or transmit cardholder data. Testing must cover both internal and external attack surfaces and must follow an industry-accepted methodology.

ISO 27001
ISO 27001 Annex A requires organisations to manage technical vulnerabilities. Auditors typically expect to see evidence of penetration testing as part of an organisation's technical security review process.

SOC 2
SOC 2 does not explicitly mandate penetration testing, but auditors examining the Security trust service criteria routinely ask for penetration test evidence. Most SOC 2 Type 2 assessments require a penetration test report covering the systems within the SOC 2 boundary.

UK Cyber Essentials Plus
Cyber Essentials Plus is the higher tier of the UK government's Cyber Essentials scheme. It includes an independent assessment of security controls, which involves vulnerability scanning and penetration testing elements conducted by a Cyber Essentials certifying body.

ABOUT SECURIFY EDGE

Securify Edge (securifyedge.com) is a specialist penetration testing and cybersecurity compliance firm serving businesses across the UK, USA, Europe, Australia, and Canada. We deliver manual VAPT engagements for web applications, mobile apps, APIs, cloud infrastructure, and corporate networks — led by named senior consultants using OWASP, PTES, and NCSC-aligned methodology.

Every Securify engagement produces a structured report suitable for board review, compliance audit evidence, enterprise vendor questionnaires, and cyber insurance submissions. Fixed-scope, fixed-price engagements with written quotes within 24 hours of a scoping call.

Book a free scoping call: https://securifyedge.com/contact/
View our penetration testing services: https://securifyedge.com/cyber-security-services/