You've failed a pen test... what now?

What is a penetration test?

A penetration test (or pen test) is a security exercise where a cybersecurity expert attempts to find and exploit vulnerabilities in a system. The goal is to simulate real-world attacks and identify any weak points before hackers do.

You’ll often hear another term used alongside ‘pen test’: vulnerability scan.

The distinction matters.

• A vulnerability scan is automated. It scans your system and flags potential issues.
• A penetration test is manual and hands-on. A real person actively tries to exploit weaknesses.

Think of it this way:

• A vulnerability scan is like a smoke detector; it tells you there might be a fire, but also screams at you when you burn the pasta.
• A penetration test is a firefighter walking through your building, showing you exactly what will burn and how fast.

Why do pen tests matter

A large portion of cybercrime is not targeted; it's opportunistic. Attackers run vulnerability scans on thousands of sites and exploit any vulnerabilities they find. If your system has a known vulnerability, it's only a matter of time before someone finds it and exploits it. Your best defense is to beat them to the punch and plug the holes.

Most penetration test reports are structured around common vulnerability frameworks such as the OWASP Top 10. The OWASP Top 10 lists the most common web application risks, including:

• Broken authentication
• Injection vulnerabilities (SQL injection, command injection)
• Security misconfiguration
• Cross-site scripting (XSS)
• Sensitive data exposure

So while it makes it easier for you to fix vulnerabilities, it also doubles as a shopping list for attackers. If your report references OWASP findings, it simply means your application contains one or more well-known vulnerability types.

You failed a pen test

You commissioned a test. The report comes back. It lists a number of Critical security vulnerabilities in your web application. What now?

First, take a deep breath; it's not as bad as it sounds. A failed pen test can be stressful, but remember, it's not a breach. Penetration tests are diagnostic, not catastrophic.

The goal of a penetration test is to find vulnerabilities, so if your report has findings, the test worked. The report is showing you where you might have problems, not where you’ve already been compromised.

Also, not everything labeled as critical is actually critical.

Severity is not impact

Most reports will classify findings as critical, high, medium, low, and informational. This is a useful starting point, but not the full picture.

Severity reflects technical risk, not business impact. And those are not always the same thing.

For example:

• A Distributed Denial of Service (DDoS) vulnerability found in a package that is only used to build your application and not shipped in production may be labeled critical, but has little real-world impact.
• A flaw that exposes your customer database might be labeled high, yet would be catastrophic for your business if exploited.

Context Matters.

How to prioritize

I know it's tempting to just fix problems so you can pass the pen test, but that’s the wrong goal. Passing the test is not the goal in itself; having a secure system is. To do that, you need to prioritize by business impact.

Ask yourself:

• Can this vulnerability expose customer data?
• Can it allow remote code execution?
• Can it compromise authentication?
• Is the vulnerable component even accessible to attackers?

No penetration tester understands your system as deeply as your development team. That context is essential.

Categorize

In an ideal world, you would fix all the errors all at once, but in reality, you need to prioritize. A good idea is to use the Eisenhower Matrix. The Eisenhower Matrix helps prioritize tasks based on urgency and importance. For you, this might look like:

Where to start?

Once you have your priorities, start with true critical vulnerabilities. They pose the most immediate threat. Examples of truly critical vulnerabilities:

• SQL Injection
• Authentication bypass
• Remote code execution
• Server-side request forgery
• Exposed admin interfaces

These are vulnerabilities that can lead to data compromise or system takeover. In other words, they are immediately exploitable and can compromise business. In our previous example, that one vulnerability that allows a hacker to access your customer database? Yeah, start with that.

In simple terms, put out the fire before repainting the walls.

What to fix next

What you do next is up to you, but we wouldn’t jump straight into the next “high” tasks. Instead, target security quick wins. Quick wins could be as simple as updating dependencies or making small refactors. For example, for you these could be:

• Updating outdated dependencies
• Closing unnecessary ports
• Updating server packages
• Enabling security headers
• Removing debug endpoints
• Fixing misconfigured permissions

Why?

• They reduce the total attack surface quickly
• They build momentum
• Multiple “small” issues can sometimes be chained into critical exploits

For us, reducing the total number of vulnerabilities quickly matters more than tackling them one by one.

Implement Fixes Carefully

Security fixes should follow the same discipline as normal development.

• Implement change
• Test functionality
• Confirm vulnerability is resolved
• Ensure no new vulnerabilities were introduced

This is especially important when fixing authentication or database-related vulnerabilities. Be prepared to get your hands dirty, or hire someone who can help you do it if you are not a security expert or developer.

After the fixes

You've made changes, thoroughly tested, now what? Well, you are most of the way there. Now you need to formally validate your work.

• Run vulnerability scans
• Request a retest from the pen test provider
• Verify the findings are closed
• Celebrate... briefly

When to call in the experts

Some findings require architectural or framework-level changes. For example, in Django applications, common penetration test findings include things like:

• insecure authentication or session handling
• missing security headers
• unsafe file uploads
• cross-site scripting vulnerabilities
• outdated Python or Django dependencies

Django provides strong built-in protections, but only if configured correctly. If you have an experienced Django development team, they can usually address these issues internally. But many companies running successful web applications don’t have a dedicated engineering or security team. Sometimes the original developers have moved on, or the application is maintained by a small product team.

We can help

At djangsters, we help teams move from failed penetration tests to secure applications. We can assist with:

• Reviewing and explaining reports
• Prioritizing vulnerabilities based on real risk
• Fixing Django-specific issues
• Resolving OWASP findings
• Hardening your deployment and configuration
• Adding automated tools like Dependabot to keep dependencies secure

Whether the fix is simple or architectural, having experienced guidance can significantly reduce the time to a solution. If you’ve recently received a report listing critical security vulnerabilities in your web application, feel free to reach out. We’re happy to review the findings and help you build a clear remediation plan.

Final thoughts

We've said this before, but security is an ongoing practice, not a one-time event. Passing a pen test today does not guarantee you'll pass one tomorrow. You need to keep up with it to avoid failing the next security audit. Keep your application up to date, and occasionally run vulnerability scans, and if something pops up, fix it. If this sounds like whack-a-mole, then congratulations, you are starting to understand why security is such a big topic.

The goal isn’t just to pass tests, it’s to reach a point where passing them is routine, not stressful.