About the Author
Ahmar Imam wrote this article, drawing on over a decade of combined experience in application security, threat intelligence, identity protection, and incident response. Ahmar is a founder of D3C Consulting, where his team monitors emerging attack campaigns daily and works directly with enterprise security teams and individual consumers to mitigate data breach risks.
Reviewed by: Senior Threat Intelligence Analyst | Certified Information Security Professional (CISSP) | Identity Management expert
Your auditor just asked for a custom app penetration test. Your deadline is close. And your app is not some off-the-shelf SaaS tool. You built it yourself, on your own code.
Now you need proof that it holds up.
This guide breaks down what SOC 2 Type II actually asks for, why a basic scan will not cut it, and how to get audit-ready testing done fast, without guessing.
Does SOC 2 Type II Require A Pentest?
The SOC 2 rulebook has a rule called “Trust Services Criteria”. It doesn’t mention “penetration testing” by name. However, this doesn’t mean it’s not important. The rules say you need to show that your security measures are working. Auditors need real proof, not just a paper with policies. A penetration test is one of the best ways to give them that proof. So, even though the rules don’t use the word “penetration test,” most auditors see it as an important part of checking your security.
Which SOC 2 Criteria Demand Testing?
Three parts of the criteria matter most:
CC4.1
You must verify that your controls function effectively in practice, not just on paper. Regularly test and assess the controls to ensure proper implementation and that they achieve the intended results. Conduct audits, gather feedback, and analyze performance data to confirm that the controls operate as designed and address the risks they aim to mitigate. Keep documentation updated to reflect any adjustments or improvements based on these evaluations to enhance the overall effectiveness of your control systems.
CC6.1 and CC6.6
To prevent unauthorized access to your systems, you must implement strong security measures. This includes establishing robust security protocols, utilizing firewalls, and requiring users to authenticate. Usually, organizations accomplish this through complex passwords or biometric verification. Regularly monitoring access logs and conducting audits to identify any suspicious activities are also a must. Additionally, provide training for employees on security best practices to strengthen your overall defense against potential breaches.
CC7.1 and CC7.2
You need to find and address vulnerabilities or weaknesses quickly. If you don’t, someone else might exploit them first. Conduct thorough assessments to uncover potential risks. Take timely action to mitigate these risks. This proactive approach protects your interests effectively. It also strengthens your overall strategy and resilience.
None of these say “hire a pentester.” But try proving any of them without one. Most companies cannot.
What Happens If You Skip Testing?
Your auditor asks how you know your app is secure. “We think it’s fine” does not survive that question.
Skip the test, and you risk a stalled audit, a delayed SOC 2 report, and a hard conversation with the enterprise client who is waiting on that report to sign your contract.
Why Do Automated Scans Fail SOC 2?
This is a common pitfall that many teams encounter. They decide to utilize an automated scanning tool because it’s cost-effective and provides results in a matter of minutes.
After the scan is complete, they present the generated report to their auditor, expecting a smooth approval process. However, the outcome is often disappointing: the report is rejected.
This typically happens because automated scanners, while useful, may not capture the full scope of vulnerabilities or issues that a thorough, manual review would identify, leading to gaps in compliance and security assessments.
Why Won’t A Vendor Scan Pass an Audit?
A scanner checks for known bugs on a list. It cannot log into your app, walk through your checkout flow, or test whether one customer can see another customer’s data. Your app is not templated. It has custom logic that your team wrote by hand. A scanner has never seen that logic before, so it cannot judge it. Auditors know this. A scan report alone rarely satisfies CC7.1.
What Evidence Do Auditors Expect?
They want manual testing. A real person tries to break into your app the way an attacker would — testing your login screen, your user roles, your APIs, and your business logic. Then they write down exactly what they found and how to fix it. That is the only kind of report that holds up.
What Should Your Custom APP Pentest Scope Include?
Your custom app scanning is different from SOC2. For your custom app scanning, Not every part of your business needs testing. SOC 2 only cares about the systems inside your audit scope. Test the wrong thing, and you waste time and money.
Is Your Custom App Code In Scope?
Yes, almost always. If you built the app, or you are building it for a client under contract, that code sits inside your SOC 2 boundary. This includes:
- Login and authentication flows
- User roles and permissions
- Your APIs
- Any custom business logic
Does Your Cloud Setup Need Testing?
Your AWS, Azure, or GCP setup around the app matters too. Testers should check how your app talks to your cloud environment, not just the app in isolation.
What Falls Outside Your Test Scope?
From your marketing website to internal HR tools, anything that sits outside the system your SOC 2 report describes must not be included in your test scope. Testing these wastes budget and adds noise, which your auditor does not need.
How Often Does SOC 2 Require Testing?
SOC 2 Type II does not check a single day. It checks a window of time, which usually comprises of six to twelve months. Your controls need to work the whole time, not just on test day.
What’s The Standard Testing Schedule?
There is no one rule to follow. But Most auditors expect one test per year, which must be done around your audit window.
When Do You Need A Retest Sooner?
Any time you ship a major change into your system, you nee a restest. Whether it is a new login system or a payment flow or you have just added a big new feature. A fresh test after a big change shows your controls kept working, even after your app is changed. Testing needs to keep pace with you, not lag a year behind.
What Makes A Pentest Report Audit-Ready?
Not all penetration test reports meet the standards expected by auditors. A poorly constructed report can lead to increased workload rather than reducing it.
What Details Belong In The Report?
A strong report shows:
- Exactly what got tested, and when
- Every finding, ranked by risk
- Clear steps your engineers can follow to fix each issue
- Proof that fixes actually worked, through a retest
Why Is A Retest Non-Negotiable?
Finding a bug means nothing if nobody checks the fix. Auditors want to see that you closed the gap, not just found it. A retest closes that loop and turns your report into solid evidence.
How Do You Choose A Pentest Vendor?
Choosing the right penetration testing vendor is essential for your organization’s security. An incorrect choice wastes time and money. It may also require a second attempt to achieve the desired security level. When evaluating potential vendors, consider these key factors:
Expertise and Experience
Look for vendors with a strong track record in penetration testing. Check their experience in your specific industry and environments. This knowledge can greatly affect the relevance of their findings. Verify their certifications, such as OSCP, CEH, or CISSP. These credentials demonstrate their commitment to professional standards.
Reputation and Reviews
Investigate the vendor’s reputation. Read reviews, testimonials, and case studies from previous clients to gauge satisfaction. Reach out to businesses in your network for recommendations based on their experiences.
Methodology
Understand the vendor’s approach to penetration testing. Ensure they follow established frameworks like OWASP, NIST, or PCI DSS. They should also customize their methodology to fit your needs. A thorough methodology includes planning, execution, reporting, and remediation steps.
Scope of Services
Evaluate the range of services the vendor offers. Some specialize in specific types of testing, such as network or application testing. Confirm they can provide the services you require, such as web application testing, social engineering, or compliance testing.
Reporting and Communication
Analyze how the vendor conveys their findings. They should present a clear, comprehensive, and actionable report. It must outline vulnerabilities and provide practical recommendations for remediation.
Engagement Process
Discuss the engagement process in detail. Clarify the initial consultation, project timeline, and deliverables. Clear communication about expectations and milestones keeps the process smooth.
Cost and Value
Consider your budget alongside the value you receive. A lower price may not guarantee better service. Assess whether the vendor’s pricing aligns with the quality and thoroughness of their offerings.
Follow-Up Support
Determine if the vendor offers ongoing support after the penetration test. Effective follow-up helps guide your team in remediation efforts and ensures they address vulnerabilities adequately.
By thoroughly vetting potential vendors based on these criteria, you can improve your chances of choosing a partner that effectively meets your security needs.
Which Vendor Red Flags Should You Avoid?
Skip vendors who:
- Only run automated scans and call it a pentest
- Quote you a price only after a long sales call
- Do not know how to read your custom auth logic
- Cannot explain how their findings tie back to SOC 2 criteria
Which Vendor Qualities Actually Matter?
Find a tester who:
- Reads and tests your actual code, not a template
- Gives you a fixed price upfront, without a discovery-call runaround
- Understands AWS, Azure, and GCP environments
- Includes a retest once you fix what they found
Why Does D3C Fit Custom-Built Apps?
Most pentest vendors build their process around shared SaaS products. That is not your situation.
D3C Consulting tests the code your team actually wrote — your auth flows, your business logic, your APIs — on AWS, Azure, or GCP. Not a templated scan.
Here is how it works:
- Scope first. Fill out a short async form. Most engagements get priced from this alone, no sales call needed.
- Manual testing. A real tester works through your app, targeting the logic only you built.
- Report and retest. You get a clear report your engineers can act on, plus a free retest once fixes ship.
Pricing stays fixed, based on your app’s complexity, not your headcount—no surprise invoices after the fact.
Running a dev shop or consultancy building apps for clients? D3C Consulting can plug in as your named or white-labeled testing partner, so the client relationship stays yours.
What’s Your Next Step Toward Compliance?
Your auditor’s deadline is not moving. The good news: getting audit-ready testing does not have to eat your whole quarter.
Start with the Custom Code Pentest Readiness Checklist — 15 questions engineering leads use before a due diligence review or a first pentest. It shows you exactly what “ready” looks like before you pay anyone.
Or skip straight to a fixed-price quote and get your scope priced without a sales call.
