SOC 2 reports in as little as 4 weeks.

We offer SOC 1, SOC 2, and HIPAA reporting. SOC 1 covers controls relevant to your customers' financial reporting. SOC 2 covers controls over security and the other Trust Services Criteria. HIPAA is mapped into your SOC 2 report.

Ask who is requesting the report and why. If a customer's finance team or external auditors want assurance over numbers that flow into their financial statements, that is usually SOC 1. If a customer's security or procurement team wants to know how you protect their data, that is usually SOC 2. Some companies need both.

Companies typically start when security questionnaires and customer reviews begin to ask for one, or when deals stall without it. Starting before any customer asks can add overhead without a clear return, and starting after deals are blocked adds delay.

A Type I looks at whether your controls are designed and in place as of a single date. A Type II tests whether those controls operated over a period of time. A Type II shows customers the controls worked in practice. Many companies start with a Type I and follow it with a Type II, and a Type II can also be your first report.

Yes. Zero Day CPA, PC is a licensed CPA firm, and every report is signed by a licensed CPA. Only a licensed CPA firm can issue a SOC 2 report.

They are the five categories a SOC 2 report can cover: Security, Availability, Confidentiality, Processing Integrity, and Privacy. Security is built on the Common Criteria (CC1 through CC9), which cover areas like the control environment, risk assessment, access, system operations, and change management.

Security is the only required criterion, and it is included in every SOC 2 report. Availability, Confidentiality, Processing Integrity, and Privacy are optional and added at your request. You cannot scope a report down to a single optional category without Security.

Companies typically include Availability when they have uptime commitments in customer contracts, or when customers depend on continuous access to the system. It is common for hosted software.

Companies typically include Confidentiality when contracts or NDAs require them to protect specific business information, such as proprietary data, source code, financials, or customer configurations. It covers sensitive business information generally, not only personal information.

Companies typically include Processing Integrity when their system calculates, bills, matches, scores, or transforms something customers rely on being accurate. Examples include payment platforms, billing systems, and systems that produce scores or outputs customers act on.

Companies typically include Privacy when they collect and manage personal information directly from individuals under their own privacy commitments, such as consumer apps or platforms where people sign in with their own identity. It often does not apply to a company that only receives data pushed to it by business customers, since the relationship with the individual sits with the customer.

No. Industry is a starting point for the conversation, not a rule. What drives scope is what your business does, what you have promised customers, and what data moves through your system. Companies in healthcare and education often consider Confidentiality and Privacy, legal technology companies often consider Confidentiality, and payment and billing platforms often consider Processing Integrity. Your cloud provider does not change which categories apply.

They usually start from their customer contracts and security questionnaires, because those show what customers are asking for. Added criteria expand the testing and the evidence required, so they add time and cost. We can walk through your commitments on a call so you can decide what fits your situation.

A subservice organization is a vendor that performs a function relevant to your criteria on your behalf, like a cloud hosting provider. In the usual carve-out method, your report excludes their controls and references their own SOC 2 report instead. You are expected to review those vendor reports as part of your own vendor management.

Those are Complementary User Entity Controls. They are responsibilities the report places on your customers, such as managing their own user access inside your platform. They show where your responsibility ends and the customer's begins.

Yes. We map HIPAA requirements into your SOC 2 report. HIPAA is not a certification and there is no official HIPAA certificate, so the report is how you show a customer how your controls line up with the HIPAA Security Rule.

A Type I report is delivered about 4 weeks after the as of date. A Type II report is delivered 4 to 6 weeks after the observation period ends. A first Type II commonly uses a three month period, and a longer period is your choice. We book about 6 to 8 weeks out for scoping and fieldwork, so completing the intake form and signing the engagement letter early helps us reserve time for you.

We confirm scope and criteria at kickoff and set up access to your evidence. Fieldwork and testing follow, along with questions as we review. After testing, you receive a draft report to check for factual accuracy, then you sign a representation letter and the final report is issued. For a Type II, the observation period comes first and testing is done after it ends.

No. The observation period has to run for the time period the report covers. The faster options are a Type I now and a Type II after it, or helping us move quickly by assigning someone to answer evidence requests promptly.

As a ballpark, a Type I typically starts around $5,000 and a Type II around $7,000. Final pricing depends on the size and scope of the audit, including company size and how many criteria are included. We charge a fixed fee per audit, with Security included. Billing is 50% when you sign the engagement letter and the balance when you receive the draft report.

Yes. Criteria beyond Security add testing scope, so they are priced on top of the base fee. We will give you a single total for the combination you choose before you sign.

We audit directly in Vanta, Drata, and Secureframe, and we have extensive experience with all three. A GRC platform is not required, but it makes the audit easier for you and for us. If you do not use one, we can collect evidence through a shared tracker instead.

Review the control areas we test and make sure each one is operating and documented. The common ones are quarterly access reviews, offboarding, background checks, security awareness training, policy acknowledgments, vendor reviews, incident response testing, change management, vulnerability scanning, logging and monitoring, encryption, and multi-factor authentication. We send an environment-specific evidence request list at kickoff.

No. A readiness assessment is not required to hire us. We only audit, so readiness and control building are done by separate firms under their own contracts. If you want one, we can introduce preferred partners, and we receive no compensation of any kind for introductions.

Missing or imperfect evidence does not automatically end the audit. If a control did not operate the way it should have, it is noted as an exception in the report, and you can provide a management response. Many reports include some exceptions.

A pen test is not technically required for SOC 2, but it covers a lot of what auditors look for under the related criteria, so we recommend one. We do not perform pen tests for companies we audit. The tester should be independent of the team that builds and operates your system. Findings that stay open without a remediation plan are more likely to show up as an exception.

Often yes. SOC 2 expects scans on a periodic basis and after significant changes, with timely remediation, but it does not say who has to run them. Contracted staff working under your direction can run scans if your policy covers them and someone at your company reviews the results. A scan does not replace a pen test, and a pen test does not replace scans.

We look for a documented process that matches what your team actually does. That typically means changes are requested and recorded, reviewed, approved by someone other than the person making the change, tested before release, and logged. We audit the process the same way no matter who or what writes the code.

No. Cyber insurance is not a SOC 2 requirement and not carrying a policy is not an exception by itself. It connects to risk mitigation under criterion CC9.1, and some customer contracts require it separately.

SOC 2 has no fixed checklist, and the report is an opinion rather than a pass or fail certificate. Your controls have to meet the criteria and match what you describe in your system description. A written policy does not count unless it is actually followed, and a Type II tests that over the period. *If you want to walk through your scope with us before deciding, book a call and we will go through it with you.*