SEC-3 Tech Due Diligence

Tech Due Diligence SEC-3: Vulnerability Management and Penetration Testing

What This Control Requires

The assessor evaluates the vulnerability management programme, including automated scanning practices, penetration testing frequency and scope, vulnerability remediation SLAs, and the overall maturity of the security testing programme.

In Plain Language

Every system has vulnerabilities. What separates mature organisations from the rest is whether they find those vulnerabilities proactively and fix them before someone else exploits them.

In a tech DD review, we evaluate how thoroughly and how often you scan for security weaknesses, what your most recent penetration test uncovered, how quickly you remediate findings, and whether there is a genuine system behind the effort rather than ad-hoc fixes. We look for automated scanning integrated into CI/CD, regular external penetration testing (annually at minimum, ideally semi-annually), clearly defined remediation SLAs tied to severity, a vulnerability tracking system that gives real visibility into the security backlog, and evidence that findings actually get fixed rather than just acknowledged.

The penetration test report is one of the most closely examined documents in any DD review. We evaluate not just the findings themselves but the scope of the test (was it comprehensive or cherry-picked?), the methodology used, and how the organisation responded. A clean report is good. A report with critical findings that were promptly remediated is also good. A report with old, unresolved critical findings is a serious red flag.

How to Implement

Build automated security scanning into multiple stages of your development and deployment pipeline. Run SAST (Static Application Security Testing) in CI to catch code-level issues, DAST (Dynamic Application Security Testing) against staging environments, SCA (Software Composition Analysis) for dependency vulnerabilities, and infrastructure scanning for servers and cloud configurations.

Commission external penetration testing at least once a year from a reputable firm with experience in your technology stack and industry. Make the scope comprehensive: web application testing (OWASP Top 10), API testing, authentication and authorisation testing, infrastructure and network testing, and social engineering where relevant.

Define remediation SLAs based on severity and hold the team to them. Critical vulnerabilities (CVSS 9.0+) should be remediated or mitigated within 48 hours. High (CVSS 7.0-8.9) within one week. Medium (CVSS 4.0-6.9) within 30 days. Low (CVSS 0.1-3.9) within 90 days.

Track every vulnerability in a centralised system with clear ownership, due dates, and status updates. Produce regular reports showing total open vulnerabilities by severity, SLA compliance rates, new versus remediated trends (burn-down chart), and age analysis of open items.

Once your product and processes are mature enough, consider a bug bounty programme through HackerOne or Bugcrowd. Start with a private programme and widen it as your response processes prove reliable.

Make security testing part of the development culture, not just a compliance exercise. Invest in developer security training, include security in code review checklists, and treat security improvements as genuine wins rather than overhead.

Evidence Your Auditor Will Request

Automated security scanning configuration and recent reports (SAST, DAST, SCA)
Most recent external penetration test report
Vulnerability remediation SLAs and compliance metrics
Vulnerability tracking system with current open findings
Bug bounty programme details (if applicable)

Common Mistakes

No penetration testing ever conducted or last test was over 2 years ago
Penetration test findings remain unresolved months after the engagement
Automated scanning produces findings but no one reviews or acts on them
Vulnerability scanning only covers external-facing systems; internal systems unassessed
No defined SLAs for vulnerability remediation; fixes happen when convenient

Related Controls Across Frameworks

Framework	Control ID	Relationship
ISO 27001	A.8.8	Related
SOC 2	CC7.1	Related

Frequently Asked Questions

Will a penetration test with findings be a problem for due diligence?

Not if you are addressing them. Every system has vulnerabilities - what counts is that you identify, track, and fix them systematically. A pentest report with findings and clear evidence of prompt remediation is actually a positive signal of maturity. A company claiming zero vulnerabilities is either not looking hard enough or not being straight with you.

Is automated scanning sufficient or do we need manual penetration testing?

You need both. Automated scanning catches known vulnerability patterns efficiently, but it misses business logic flaws, complex attack chains, and novel vulnerabilities. Manual penetration testing brings the creative, adversarial thinking that tools simply cannot replicate. Think of them as complementary rather than interchangeable.

Track Tech Due Diligence compliance in one place

AuditFront helps you manage every Tech Due Diligence control, collect evidence, and stay audit-ready.

Start Free Assessment