Preparing for a penetration test or SOC 2 / ISO 27001 audit: cleaning up your codebase first

Key takeaways

• External penetration tests are expensive and time-boxed; spending those days having pentesters report preventable source-code bugs wastes budget and delays customer deals.
• Running a full-repository review two to four weeks before an external engagement lets your team fix auth bypasses, injection sinks and resource-exhaustion flaws before testers begin.
• SOC 2 and ISO 27001 auditors look for repeatable secure-development controls, documented triage dispositions and evidence that vulnerabilities are tracked to remediation.
• Dokima produces timestamped HTML reports, severity breakdowns and persistent finding dispositions (Confirmed, False Positive, By Design, Mitigated) that give engineering leads clear internal audit evidence.

Why clean up your source code before paying for a penetration test?

For many B2B software companies, the trigger for taking application security seriously is an enterprise procurement questionnaire, a SOC 2 Type II or ISO 27001 audit, or an upcoming external penetration test.

External penetration tests are valuable, and Dokima does not replace independent human assurance. However, a typical pen test costs £10,000 to £30,000+ and runs in a fixed five-to-ten-day window. If external testers spend the first three days discovering straightforward broken access control, path traversal, unauthenticated internal routes or missing input bounds that were sitting plainly in your source code, two things happen:

1. You pay specialist rates for findings you could have caught internally before the engagement started.
2. Your final report comes back with High or Critical findings, forcing an emergency engineering sprint and a paid re-test while an enterprise customer’s security review is on hold.

Running a comprehensive source-code security review with Dokima ahead of the engagement clears out code-level vulnerabilities first, allowing external testers to spend their limited time on live infrastructure, complex multi-system chains and runtime configuration.

What external testers usually find in the first 48 hours

When white-box or grey-box penetration testers start an assessment, they immediately look for high-leverage flaws across your application’s entrypoints:

• Inconsistent authorisation (IDOR and role bypass): Endpoints where an authenticated user can read or modify another tenant’s records by changing an ID parameter.
• File, path and archive handling flaws: Upload, download, preview or backup features that allow reading arbitrary files, traversing outside a workspace directory, or exhausting server memory.
• Authentication and token lifecycle edge cases: Password reset tokens, invitation links, webhook signatures or session revocations that fail to invalidate properly.
• Injection and unsafe command execution: Places where user-controlled fields reach shell commands, template engines, SQL queries or SSRF targets.

Because Dokima has direct read-only access to your full Git repository, its foundation stages and targeted hunting lenses systematically inspect every one of those code paths, including obscure routes that black-box testing might miss.

A practical four-week playbook before an external pen test

Engineering teams can use Dokima’s 21-day free trial or an active subscription to run a structured pre-assessment clean-up:

Week 1: Run a full baseline sweep

Install Dokima on Linux or macOS, connect your preferred AI runner (Claude, Codex or OpenCode), and run a full sweep (dokima sweep --mode full) on the repositories in scope for the upcoming test. Let Dokima map the attack surface, challenge candidate findings, and generate dokima-report/index.html.

Week 2: Triage and fix Critical and High findings

Review the validated Critical and High severity findings first. Every Dokima finding includes exact file and line citations, a step-by-step explanation of the vulnerability, and concrete remediation steps. Assign fixes to the engineers who own each component and mark non-issues or intentional behaviours with explicit dispositions (By Design, Mitigated, or False Positive).

Week 3: Run an incremental verification sweep

Once fixes land on your main branch, run another sweep. Dokima’s incremental follow-up and deterministic fingerprinting verify that fixed vulnerabilities no longer reproduce and check that the patches did not introduce regressions in sibling code paths.

Week 4: Hand a cleaner system to your external testers

Enter the external penetration test with the obvious code-level bugs already resolved. If you are conducting a white-box assessment, you can even use Dokima’s architectural component map and triaged report to brief your testers on the system’s design and intentional trade-offs.

How Dokima supports SOC 2 and ISO 27001 engineering controls

Compliance frameworks such as SOC 2 (Common Criteria CC7.1 and CC8.1) and ISO/IEC 27001 (Annex A 8.8 Management of technical vulnerabilities and 8.28 Secure coding) do not prescribe a specific tool brand. Instead, auditors ask for evidence that your organisation has a repeatable process to:

1. Identify technical vulnerabilities in custom software.
2. Evaluate and classify findings by severity.
3. Track remediation or document risk acceptance.

Dokima makes this straightforward without heavyweight enterprise GRC software:

• Self-contained HTML reports: Every sweep produces a timestamped report in dokima-report/ showing the repository commit, review coverage, severity counts and detailed findings.
• Persistent triage dispositions: Decisions recorded in the terminal dashboard or CLI (Confirmed, False Positive, By Design, Mitigated) persist in workspace state across runs and appear in a dedicated dispositioned view in the HTML report.
• Private team sharing: Teams can keep reports strictly local on their own infrastructure or publish them privately to Dokima.net so engineering leads can review status across repositories in one place.

From annual audit scrambles to continuous review

The biggest benefit of setting up Dokima before an audit is what happens after the audit finishes. Instead of letting security review lapse for another eleven months, Dokima’s background worker continues reviewing new code as your team ships.

Inspect our 57-finding sample report to see the exact report format your team will work with, or start a 21-day free trial today.