SOC 2 is an AICPA attestation framework that checks how a service company protects customer data. A Type I report confirms security controls are designed correctly at one point in time. A Type II report goes further: an independent auditor tests that those controls worked over a period, usually 3 to 12 months, which is why buyers prefer it.
What is the difference between SOC 2 Type I and Type II?
Both reports are issued by an independent CPA firm and both cover the same framework. The difference is what the auditor tests. A Type I report answers "are the right controls in place today?" A Type II report answers "did those controls actually operate, day after day, over the whole period?"
| SOC 2 Type I | SOC 2 Type II | |
|---|---|---|
| What it assesses | Design of controls | Design and operating effectiveness of controls |
| Time covered | A single date | An observation period, commonly 3 to 12 months |
| How the auditor tests | Reviews policies, configurations and walkthroughs | Also samples evidence across the period, such as access reviews, change tickets and incident records |
| Typical use | A first report for a company new to SOC 2 | The report most enterprise buyers ask for |
| What it tells a buyer | The vendor has a sensible security programme on paper | The vendor ran that programme consistently, with any exceptions disclosed |
A simple way to think about it: Type I is a photo, Type II is a video. If you are choosing software that will hold your employees' salaries, bank details and your customer pipeline, the video is what you want to see.
One terminology point. SOC 2 is an attestation, not a certification, so there is no "SOC 2 certificate". In practice, vendors say they are "SOC 2 compliant" or "have a SOC 2 Type II report", and both mean an auditor has issued a report on their controls.
What are the 5 Trust Services Criteria?
SOC 2 reports are built on the AICPA's Trust Services Criteria. A vendor chooses which criteria are in scope. Security is always included; the other four are optional and are added when they matter for the service.
- Security (required). Systems and data are protected against unauthorised access, disclosure and damage. This covers access control, change management, monitoring, incident response and more. It is often called the "common criteria".
- Availability. The system is available for operation and use as committed, which covers areas such as capacity planning, backups and disaster recovery.
- Processing integrity. System processing is complete, valid, accurate, timely and authorised. Relevant when a service calculates or transforms data, such as payroll.
- Confidentiality. Information designated as confidential is protected, for example through encryption, access restrictions and secure disposal.
- Privacy. Personal information is collected, used, retained, disclosed and disposed of in line with the vendor's privacy commitments.
When you review a report, check which criteria are in scope. A security-only report is common and perfectly valid, but if uptime is critical to you, it is reasonable to ask whether availability is covered, or how the vendor evidences it some other way.
What does a SOC 2 report contain, and how do you request one?
A SOC 2 report is a long document, often running to dozens of pages. You don't need to read every page, but you should know where to look. Most reports have these sections:
- Independent auditor's report (the opinion). Read this first. An "unqualified" opinion means the auditor found the controls suitably designed and, for Type II, operating effectively. A "qualified" opinion means there were significant issues in some areas.
- Management's assertion. The vendor's own statement about its system and controls.
- System description. What is in scope: the product, infrastructure, people, processes and any subservice organisations, such as the cloud hosting provider.
- Controls, tests and results. For Type II, each control is listed with how the auditor tested it and whether any exceptions were found.
- Complementary user entity controls. Things you, the customer, are expected to do, such as managing your own users' access and reviewing who has admin rights.
Exceptions are not automatically a red flag. Most Type II reports have a few. What matters is how serious they are and whether management's response explains how they were fixed.
To get a report, ask the vendor's sales or security team, or look for a trust or security page on their website. SOC 2 reports are restricted-use documents, so vendors usually share them under an NDA. Some vendors also publish a SOC 3 report, a short general-use summary you can read without an NDA, but it doesn't include the detailed test results.
How does SOC 2 compare with ISO 27001 and GDPR?
These three are often mentioned together, but they are different kinds of things. SOC 2 and ISO 27001 are ways of independently checking a security programme. GDPR is a law.
| SOC 2 | ISO/IEC 27001 | GDPR | |
|---|---|---|---|
| What it is | Attestation report under AICPA standards | International standard for an information security management system | EU regulation on personal data protection |
| Who checks it | Independent CPA firm | Accredited certification body | Data protection authorities, if issues arise |
| Output | Detailed report, shared under NDA | Public certificate, with a scope statement | No certificate; compliance is an ongoing legal obligation |
| Typical cycle | New report usually every year | Three-year certificate with annual surveillance audits | Continuous |
| Where it is most requested | Especially common with North American buyers of SaaS | Widely recognised worldwide, including in Europe and India | Applies to anyone processing personal data of people in the EU |
For buyers in India, the Digital Personal Data Protection Act, 2023 is also relevant when a vendor processes your employees' or customers' personal data. Like GDPR, it is a law, not an audit, so a SOC 2 report alone doesn't prove a vendor meets it. Ask how the vendor supports your obligations under the laws that apply to you.
What should a vendor security checklist for HR and CRM software include?
HR software holds some of the most sensitive data a company has: salaries, bank accounts, identity numbers and performance notes. CRM software holds your customer relationships and revenue pipeline. Use this checklist when you evaluate either:
- Independent assurance: a current SOC 2 Type II report, ISO 27001 certificate or both, with the observation period ending within the last 12 months.
- Encryption: data encrypted at rest (AES-256 is the common standard) and in transit (TLS 1.2 or higher).
- Single sign-on: SSO through SAML 2.0 or your identity provider, so leavers lose access when you disable one account.
- Automated provisioning: SCIM support to create and remove users automatically from your identity provider.
- Granular permissions: role-based access plus field-level controls, so a sales manager can see the team's pipeline without seeing their salaries.
- Audit logs: a record of who viewed, changed or exported sensitive data, and for how long logs are kept.
- Data location and subprocessors: where data is hosted and which third parties process it.
- Privacy compliance: how the vendor handles GDPR, the DPDP Act or other laws relevant to you, and whether it signs a data processing agreement.
- Incident response: how quickly the vendor commits to notify you of a breach.
- Exit plan: how you export all your data if you leave, and how the vendor deletes it afterwards.
For a deeper look at how access controls are designed inside a multi-tenant platform, our article on zero-trust SaaS architecture explains the principles.
How does Kiko approach security?
Kiko puts HR, sales and operations data on one shared data layer, so the security bar has to match the most sensitive data on the platform, which is usually payroll. Kiko is SOC 2 Type II compliant and GDPR and CCPA compliant, and offers HIPAA BAAs for eligible Enterprise customers.
On the technical side, data is encrypted with AES-256 at rest and TLS 1.3 in transit. Access is controlled with SSO through SAML 2.0, SCIM provisioning, role-based and field-level permissions, and audit logs. Larger organisations with procurement and security reviews can read more on the Kiko for enterprises page, and the full details are on the Kiko security page.
Frequently asked questions
Is SOC 2 mandatory?
No law requires SOC 2. It becomes effectively required when customers ask for it, which is common in enterprise and mid-market software purchases. Many security questionnaires and procurement processes accept a SOC 2 Type II report in place of answering hundreds of individual questions.
How long is a SOC 2 report valid?
A SOC 2 report has no formal expiry date, but buyers usually consider it current for about 12 months after the end of its observation period. That is why most vendors renew annually. If there is a gap between the end of the last period and today, ask for a bridge letter, in which the vendor confirms there have been no material changes to its controls.
Does SOC 2 cover GDPR?
Not directly. The privacy criterion in SOC 2 overlaps with some GDPR principles, but a SOC 2 report is not evidence of GDPR compliance. GDPR is a legal obligation that covers lawful basis, data subject rights, transfers and more, so ask vendors separately how they comply.
How do I get a vendor's SOC 2 report?
Ask the vendor's sales or security team, or check its security or trust page for a request form. Expect to sign an NDA, because SOC 2 reports are restricted-use documents. If the vendor only offers a SOC 3 summary or a badge on the website, ask for the full Type II report for your security review.
Request Kiko's security packet
If you are running a vendor review for HR or CRM software, start with the evidence. Request Kiko's security packet from the Security page to see our controls, compliance details and how we protect your data.
