A prospect’s security team has sent the questionnaire, and the last line asks for your SOC 2 report. You don’t have one yet, and the deal won’t close without it. SOC 2 readiness shows you exactly where your controls stand against the Trust Services Criteria, closes the gaps before an auditor sees them, and puts you in front of the CPA firm you choose with a system description, controls and evidence that hold up.
SOC 2 is an attestation engagement defined by the AICPA. A licensed CPA firm examines your description of a system — the services you deliver and the infrastructure, software, people, procedures and data behind them — and gives an opinion on whether the controls you describe meet the Trust Services Criteria you put in scope. Security, built on the common criteria, is required in every SOC 2. Availability, Processing Integrity, Confidentiality and Privacy are added when your customer commitments call for them.
People say “SOC 2 certification,” but there is no certificate. The result is a restricted-use report. A Type I report covers whether your controls are suitably designed and implemented as of a specific date; a Type II report adds whether they operated effectively across an observation period. Most enterprise buyers ultimately want the Type II, because it shows the controls actually ran, not just that someone wrote them down.
Teams come to SOC 2 because the market asks: an enterprise customer’s vendor-risk team, a procurement checklist, a contract clause, an investor’s diligence list. The hard part is rarely one missing tool. It is turning the way your team already works into defined controls with named owners, and producing evidence an auditor can sample without anyone scrambling to recreate it.
Your first enterprise deals bring security questionnaires a policy PDF can’t answer. A SOC 2 report answers most of them at once, and readiness gets you to that report without letting the sales pipeline stall while you work out what an auditor expects.
You have picked an audit firm or a target report date, and you don’t know what the auditor will sample. Readiness shows you the gaps against each criterion while there is still room to fix them quietly, rather than reading about them as exceptions in your report.
Your Type I proved design. The Type II tests whether controls ran across the whole observation period, and controls that work on paper often leave no trail. Readiness closes those evidence gaps before the period begins, when they are still cheap to fix.
A customer now needs Availability, Confidentiality or Privacy in scope. Readiness maps the additional criteria to what you already operate and shows you which controls are genuinely new and which only need better documentation.
A licensed CPA firm you choose
SOC 2 Type I or Type II attestation report under the AICPA Trust Services Criteria
The CPA firm that signs your report has to stay independent of the controls it examines, so it can’t design them for you. Readiness is that design and preparation work, done by a team on your side of the table, so the firm you engage examines a program that is already in shape.
A criterion-by-criterion view of where your controls meet the criteria, where they fall short, and what closing each gap involves, ranked so your team works first on what matters most to the auditor’s opinion.
A recommendation on which Trust Services Criteria categories, systems, locations and subservice organizations belong in scope, and whether a Type I or a Type II report fits where your customers are today.
Your controls written as testable statements, each with an owner, a frequency and the evidence it produces, mapped to the criteria. It becomes the backbone the CPA firm builds its testing from.
A draft description of your system written to the AICPA description criteria, covering components, boundaries, commitments and complementary controls, for management to review, adjust and own.
The information security policy set the criteria call for — access control, change management, incident response, vendor management, risk assessment, data classification, business continuity and more — written to match how your team actually works.
A documented risk assessment that identifies threats to your service commitments, rates them, and ties each significant risk to the controls that address it, as CC3 expects.
For each control, the artifact an auditor will ask for, where it lives and who produces it, so requests during fieldwork are answered from a known place instead of becoming fire drills.
Hands-on help closing the gaps: drafting procedures, setting up access reviews and logging, establishing vendor reviews, and a final readiness check before your audit firm begins.
Better found now, by people on your side, than by your assessor.
Access reviews that happen but leave no dated evidence of who reviewed what, or what was changed as a result
Offboarding that disables the identity provider account but leaves access in cloud consoles, databases or SaaS tools
Changes deployed to production with no recorded approval or peer review an auditor can sample
A risk assessment written once and never revisited after the business or the system changed
No review of vendors’ own SOC 2 reports, or of the complementary user entity controls those reports assign back to you
An incident response plan that has never been exercised
Policies adopted from a template that describe controls the company doesn’t actually operate
Backups that run but have never been restored as a test
Auditors evaluating monitoring (CC4.1) and system operations (CC7.1) commonly look for independent security testing of the application in scope, and enterprise buyers usually ask for a recent pentest summary alongside the SOC 2 report.
What the test coversFor multi-tenant platforms, customers want proof that one tenant can’t reach another tenant’s data — the question behind most Confidentiality commitments.
What the test coversAPIs are often the real edge of the system in a SOC 2 description; testing them shows the logical access controls in CC6 hold where customers and integrations connect.
What the test coversMost SOC 2 systems run in a public cloud; a configuration review shows the access, logging and encryption controls in your description are actually set the way you say.
What the test coversShows your internet-facing perimeter matches the protections your system description claims.
What the test coversNo. SOC 2 is an attestation: a licensed CPA firm issues a report containing its opinion on your system description and controls. There is no certificate, and no one outside a CPA firm can issue that report — CyberlySecure included. When a customer asks for your “SOC 2 certification,” they mean the report.
It depends on what your customers will accept. A Type I is a point-in-time report on design and implementation, and it is often enough to unblock a first deal while the Type II observation period runs. Many buyers accept a Type I with a commitment to a Type II; others insist on the Type II from the start. Readiness gives you the facts on your control maturity and your buyers’ expectations so you can make that call with your audit firm.
Security is always in scope. Add Availability if customers depend on your uptime commitments, Confidentiality if you hold their confidential business information under contract, Processing Integrity if the accuracy and completeness of your processing is the service itself, and Privacy if you collect and use personal information about individuals. Categories you don’t need add controls and testing without helping you sell, so the choice should follow your contracts and service commitments.
The CPA firm that issues your report has to remain independent, so it can’t design and operate the controls it then tests. That is why readiness and the examination are separate engagements. CyberlySecure is not a CPA firm and issues no SOC 2 report; we prepare you, and you choose the firm that examines you.
Not necessarily. Platforms can help collect evidence, but they don’t write your system description, decide your scope, or make a control operate. Readiness works with whatever you use — a platform, your ticketing system, or shared folders — and focuses on whether the evidence an auditor will sample actually exists.
The Trust Services Criteria don’t mandate one by name. The points of focus for monitoring activities list penetration testing among the separate evaluations an entity can use, and most auditors and enterprise customers expect independent testing of the system in scope. A current pentest with tracked remediation is one of the clearest ways to support CC4.1 and CC7.1.
They are subservice organizations. Your report will either carve them out — describing the controls you expect them to operate and how you monitor them — or include them, which is less common. Either way, you need to review their own SOC reports and show that you operate the complementary user entity controls those reports list.
One conversation with someone who does this work. You leave knowing where you likely stand and what readiness would involve for you.
Not sure where to start? One of our testers reviews your internet-facing footprint and sends you a short summary of what an attacker would see — free. Nothing you don’t own is ever touched, and there’s no sales sequence.
Free. No obligation.
