Five signals of real quality in assurance and security, with practical guidance on building a compliance program that supports customer TPRM, repeatable enterprise reviews and revenue growth.
When an enterprise buys your service, it takes on some of your risk. Its third-party risk management (TPRM) team needs to understand that risk, decide whether it is acceptable, and know what to do if something goes wrong. Your compliance program should make that decision easier.
For the company being reviewed, this is where compliance connects to revenue growth. The return is not just a SOC 2 report or a completed questionnaire. It is being able to navigate customer reviews reliably: specific answers, credible evidence, fewer avoidable follow-ups, and commitments you can actually keep.
That does not mean every review will pass. Customers have different risk appetites, contractual requirements and regulatory obligations. It means your company is prepared to earn approval, rather than relying on a certificate to carry a story it cannot support.
Too often, third-party risk management becomes an exercise in collecting documents rather than judging vendors. Teams send hundreds of questions, file the SOC 2 report, and record that a penetration test exists. Those documents matter, but their presence alone does not answer the question: does this vendor take security seriously?
A useful review starts with a few higher-level signals, then goes deeper where the relationship warrants it. Five signals, read with judgment and a willingness to ask why, help distinguish real assurance and security from a well-organized document pack. They complement detailed diligence; they do not replace requirements that genuinely apply.
If you are the vendor, read each signal in reverse: can a customer see it clearly in your program, your report and your answers? For the mechanics of responding, see getting through enterprise security reviews.
Security failures often involve familiar weaknesses: stolen credentials, unpatched exposed systems, support processes that can be manipulated, compromised suppliers, excess privilege, and leaked secrets. A policy stating that these risks are managed is less useful than evidence of how they are managed.
For a small vendor, a handful of engineers may have broad production access. A compromised laptop or token can then reach a great deal. The right response is not to copy a large company’s control library; it is to understand the actual attack paths and close the important ones.
Public investigations illustrate the point. The GAO’s Equifax review describes the failure to patch a known vulnerability. UnitedHealth’s congressional responses describe stolen credentials used against a Change Healthcare remote access server without MFA. Okta’s root-cause analysis describes a compromised service-account credential used to access its support system. These are examples, not a statistical ranking of breach causes.
| Failure path | What a reviewer should establish |
|---|---|
| Stolen credentials | MFA coverage, privileged access and account recovery controls |
| Known vulnerabilities | Who patches exposed systems, how quickly, and how overdue issues are escalated |
| Social engineering | How support verifies identity before changing access or releasing data |
| Third-party compromise | Which suppliers can reach customer data and how their access is bounded |
| Misconfiguration and excess privilege | Whether a foothold is contained through access limits and monitoring |
| Secrets in code and pipelines | How credentials are stored, scoped, detected, revoked and rotated |
The questions are related but separate. A serious company can hold weak assurance, and a polished report can leave important security weaknesses unaddressed. The signals below help assess both.
| Signal | What it tells a customer |
|---|---|
| Scope honesty | Whether the assurance covers the service and relevant dependencies |
| An audit that reflects how the company operates | Whether the descriptions and testing support meaningful reliance |
| A genuine penetration test, followed through | Whether testing finds relevant weaknesses and leads to action |
| Identity coverage | Whether access controls address real entry points and exceptions |
| Ownership and candor | Whether someone is accountable and honest about limitations |
A report can only assure what it covers, so the first question is whether the scope matches the real company. A SOC 2 system description is written by the vendor. How carefully it is written says a great deal.
A scope that lists only the production application may overlook the systems that support it. A careful description explains the relevant boundaries and dependencies, including support tooling, identity providers, code repositories, build pipelines, corporate IT and people with access, where they affect the service. Not every system must appear by name; the boundary must be clear enough to assess.
The useful test is whether a customer can trace how its data is handled and which systems or people can reach it, including pathways outside the production application.
What to look for:
Completeness of the system description. Does it name the systems that hold or can reach customer data, or only the production application?
Subservice organizations. Are the cloud, identity, support and data vendors named, and are they carved out or included?
Complementary user entity controls. These are the controls the report assigns to you. Assess whether these responsibilities are clear, reasonable and feasible for the customer; the number alone does not indicate poor assurance.
Categories covered. Security is the baseline SOC 2 category. Ask whether the selected additional categories align with the service commitments and customer needs; their absence is not automatically a defect.
The question to ask: "Which systems that can reach our data are outside the scope of this report, and why?" A serious vendor answers quickly and specifically. A vendor that has never considered it will tell you so without meaning to.
For your own program: keep the system description, data flows, supplier list and customer responsibilities aligned as your service changes. The scope should support the service you are selling. Our guide to what makes a SOC 2 report quality goes deeper into these report elements.
The quality of an audit shows in how specifically it describes and tests the company, not simply in how many exceptions it reports. A report with no exceptions is not a warning sign in itself. Management can prepare well and design controls around how it operates; the auditor must independently test and report what the evidence supports.
The signal is fit. Useful control descriptions explain the company’s actual practices. They name its tools, its approval paths and its cadences. Standard wording is not itself evidence of poor testing, but generic descriptions that obscure important differences leave reviewers with more questions.
What to look for:
Specificity. Do control descriptions and test procedures refer to this company's systems and processes, or could they describe anyone?
The auditor. Is it a licensed CPA firm with a visible track record, and did the vendor choose it or accept whoever the platform bundled?
Timeline. A Type II report needs an observation period. Ask which period is covered and what any accelerated timeline actually delivers.
Cost in proportion. Assess the fee alongside scope, complexity and the work performed. Price alone cannot establish audit quality.
The question to ask: "How did you choose your auditor, and what did the audit change about how you operate?" Vendors who invested in the process have an answer. Vendors who bought the cheapest route to a logo usually do not.
For your own program: choose the firm and the practitioner leading your audit for credible judgment and relevant experience, not just price or a bundled integration. Check firm credentials, and make sure the audit reflects your actual controls, including AI-enabled operations where relevant.
A penetration test provides a useful window into security priorities, especially when the company can show what it did with the findings. Testing is not the same as remediation: a known weakness can remain an open attack path until someone owns fixing or otherwise addressing it.
Two things matter: whether the test was real, and whether the results displaced other work.
A useful test has competent testers, a scope that matches the product and risk, and enough effort to examine meaningful attack paths. An automated vulnerability scan can help, but it is not interchangeable with a penetration test. A bundled or low-cost test should be assessed on its methodology and coverage, not dismissed on price alone.
Follow-through is the stronger signal. When a serious company receives high-severity findings, engineering time moves to fix them, ahead of features. That choice is security culture made visible.
What to look for:
Who tested, and for how long. A named firm and tester days in proportion to the size of the application.
Findings with substance. Few findings may warrant a closer look at the scope and methodology, but do not by themselves establish that testing was shallow.
Dated remediation. Significant findings with an owner, target date, remediation evidence and proportionate retesting or other validation.
Aged findings. What is still open from the previous test, and who accepted that risk.
The question to ask: "Show us one high-severity finding from your last test, from the report through to the retest." If no high-severity finding exists, ask for another meaningful example. Review evidence through an appropriate confidential channel, without demanding sensitive exploit details in a sales questionnaire.
For your own program: give findings accountable owners and deadlines. Be ready to show what was fixed, what remains open, who accepted the risk, and why. Do not hide unresolved issues behind the fact that a test took place.
Identity deserves its own signal because compromised accounts and credentials can provide an attacker with a direct route into sensitive systems. The useful question is not only whether MFA exists, but where it is enforced and which access paths remain exposed.
A vendor may say MFA is enabled. The useful question is where it is missing. Breaches come through the exception: the legacy VPN, the contractor portal, the service account, the admin console someone forgot.
This signal depends on the first one. A company cannot enforce MFA on systems it has not identified.
What to look for:
Coverage, stated as a list. Every externally reachable system and whether MFA is enforced, with exceptions named.
Administrators. Phishing-resistant methods for privileged access, since SMS codes and push approvals are routinely defeated.
Non-human access. How service accounts, API keys and OAuth tokens are issued, stored and rotated.
Reset and recovery. How the help desk verifies identity before resetting a password or MFA device. Recovery processes should not create an easier route around the protection.
Production access. How many people have it, and how it is granted and removed.
The question to ask: "Which systems do not have MFA enforced today, and how would someone reset an administrator's MFA?" A substantiated coverage statement matters more than an unsupported claim of no gaps; genuine complete coverage is a positive signal.
For your own program: maintain an access inventory that covers people and non-human identities. AI agents, API keys and service accounts need bounded permissions, accountable owners, secure credential handling and revocation paths; they cannot simply use the same MFA mechanism as a person.
Security culture shows in who owns security and how honestly the company discusses it. Training completion is useful evidence of participation, but it does not by itself show that people can recognize or handle the situations they face.
Real ownership means a named person is accountable, with access to leadership and proportionate authority to escalate or pause unsafe work. Engineers understand why controls exist, and leadership makes space for security work alongside product delivery.
Candor is the other half. No company can promise that it will never have a gap or incident. A vendor that describes them plainly, with what changed afterward, is showing the behavior you want on the day something goes wrong with your data.
What to look for:
A named owner. Someone accountable for security, with a reporting line to leadership, in proportion to company size.
Evidence of investment. Security spend, hiring or tooling that predates the latest sales cycle.
How questions are handled. Direct answers from people who know the environment, or deflection to the trust page.
Incident history. What has gone wrong, how they found out, and what they changed.
Detection. How they would know if an attacker were inside. Look for realistic detection and escalation paths, not just a list of monitoring tools.
The question to ask: "Tell us about the last security issue that changed how you work." Companies with a real program have a story. If there has been no significant issue, ask how exercises, testing or near misses have changed the program instead.
For your own program: name an owner for the review and the underlying controls. Give sales an approved way to describe limitations and escalate unfamiliar questions. A confident answer is valuable only if someone can stand behind it.
These signals require judgment. A five-person company with a simple product and a proportionate audit and penetration test may be doing exactly what its service warrants. The same choices in a large company handling sensitive data may need more scrutiny. Size, complexity, data sensitivity, access and service commitments all matter.
When something looks light, ask why. A narrow scope, bundled auditor or short test may have a reasonable explanation. Assess the explanation and supporting evidence rather than turning a single feature into an automatic rejection.
Where several signals are weak and the answers do not add up, write down the specific concerns and seek further evidence. The judgment should be explainable and open to challenge, not a verdict based on price or presentation.
The signals help determine the depth of review and the reliance particular evidence deserves. They are not a breach prediction or a complete vendor-risk score. Inherent exposure, regulatory requirements, business criticality and the customer’s risk appetite still shape the decision.
| Pattern | What it suggests | Proportionate next step |
|---|---|---|
| Strong, supported signals | Scope is clear, assurance is specific, findings are addressed, identity coverage is evidenced, and answers have an owner | Use the assurance for what it covers. Set reassessment and monitoring according to risk and material changes. |
| Some gaps, with credible explanations | One or two areas need additional evidence or improvement | Clarify the gaps, obtain targeted evidence and agree feasible remediation or contractual protections. |
| Multiple unresolved concerns | Descriptions, testing, access or ownership leave material uncertainties | Investigate before relying on the report. Limit data or access, require remediation, escalate, or choose an alternative if residual risk is unacceptable. |
For a company selling into enterprise, the same five signals are a practical way to prioritize compliance investment. Start with what your target customers need to know, then make sure your controls, evidence and assurance answer those questions.
What SOC 2 is really for explains why the report is a trust asset rather than a pass/fail certificate. The aim here is to turn that asset into a repeatable review process.
The business value is reduced uncertainty for the customer and reduced avoidable friction for your team. That can help qualified deals reach approval and support renewals, while preserving honest disclosure of risk.
Track time to the first complete response, repeated follow-ups, reviews delayed by missing evidence, unresolved remediation commitments, and outcomes of security reviews on otherwise qualified opportunities. Record the reasons for unsuccessful reviews where customers share them.
Do not treat a faster response as the whole result. A quick but inaccurate answer creates rework and can damage trust. A slower, candid explanation of a real limitation may be the right answer. Reliability means consistently being prepared, accurate and accountable, not winning every risk decision.
When several buyers ask the same unanswered question, feed it back into your program. It may reveal a missing control, a scope gap, an unclear commitment or simply evidence that is hard to find. This is how compliance investment becomes connected to customer needs and revenue growth.
TPRM works best when documents support judgment rather than replace it. Read the scope, understand the audit, follow the penetration-test findings, check identity coverage, and meet the person accountable for the answers.
For vendors, the lesson is equally direct: run a program that makes those signals easy to see. A well-calibrated audit helps explain what you do and independently assess the relevant controls; management remains responsible for operating them and resolving gaps.
Compliance then does more than meet a requirement. It gives customers a credible basis for trusting your service and gives your business a more reliable way to progress through enterprise diligence.
Former PwC manager, founder of AssuranceLab and former Sensiba partner and Chief Innovation Officer. Now co-founder of Throughline, focused on compliance and assurance for AI-native companies.
SOC 2 for AI-native companies: simpler stacks, agents running the program in your own tools, concise policies, and a report that covers AI in production.
ISO 42001 isn't yet an enterprise requirement. What it covers, how it compares with SOC 2 and AIUC-1, and when it's worth it for an AI company.
How to cover production AI agents in SOC 2: governance, access, change management and monitoring, with indicative criteria mappings, customer responsibilities and practical audit expectations.
Australian companies need a SOC 2 report issued under the AICPA standards by a US-licensed CPA firm, delivered by a strong local team in Australian time zones. Here's how the provider options compare, and what to check.
Experienced CTOs don't choose a SOC 2 audit firm on price or speed. They look for tech stack expertise, a tailored approach, flexible scheduling, responsiveness and year-round partnership, because those factors decide how much time the audit really costs.
What Security, Availability, Confidentiality, Processing Integrity and Privacy each cover, how often they're included, and how to decide which belong in your SOC 2 report.
Which SOC 2 report should come first? Six client cases, practical decision tables and an illustrative 18-month cost comparison explain when to start with Type 1 and when to go straight to Type 2.
How long a SOC 2 Type 2 observation period should be, how to work backwards from a customer deadline, when auditors test, why reports run late and how much buffer to build in.
A category-by-category SOC 2 budget in USD, covering audit fees, readiness, platforms, penetration testing, consultants, internal assessments and operational costs. Learn what is required, what is optional, and what a quote can leave out.
The person leading your SOC 2 audit is the most underrated factor in choosing an audit firm. Companies compare price, timelines and platform integrations, then barely ask who will actually do the work.
SOC 2 is a risk report, not a certificate. Understand how enterprise customers use it, why having a report is only base camp, and how to turn your audit into a trust asset for growing revenue.
What readiness should cover, when to involve your auditor, which gaps matter most, and how readiness, Type 1 and Type 2 can work as one continuous engagement. A practical guide to preparing for a report your customers can rely on.
CPA firm registration, signing licenses and peer review are the starting point, not proof of quality. A practical guide to checking credentials and asking the questions that matter before choosing your SOC 2 auditor.
Neither is better for everyone. The right choice depends on your customers, how you run security and where you are headed. For AI-native and AI-centric companies, SOC 2's flexible criteria usually make it the stronger starting point.
There's a basic psychology behind why most people don't like audits. Fix this, and people are surprisingly happy to do them again.
Enterprise buyers use SOC 2 as an initial qualifier, then look deeper. A quality report is what carries you through that assessment and turns your compliance investment into real trust.
Audit quality isn't service quality, and it isn't only professional standards. The real test is whether a reader of your report thinks: this tells me what I need to know.
Enterprise security teams review you in the background and rarely give feedback. What they look at beyond SOC 2, what counts as a genuine pen test, and how a quality report does the heavy lifting.
Compliance from first principles, the 95% problem, the compliance metadata AI needs, rethinking screenshots, spreadsheets and policies, and why audits should meet clients where they are.