SOC 2 Type I, design evidence done right.
SOC 2 Type I is an AICPA Trust Services Criteria attestation that examines whether your controls are suitably designed at a single point in time — the as-of date on the report. grComply seeds the full TSC 2017 structure as a comprehensive library: Security (the Common Criteria, CC1–CC9) plus Availability, Confidentiality, Processing Integrity, and Privacy, tenants activating only the categories their engagement scopes. Every artefact versions automatically, so a Type I as-of date is never ambiguous, and the platform's own auditor-observation workflow matches how a real SOC 2 examination runs.
What is SOC 2 Type I? SOC 2 Type I is an attestation report, examined under AICPA's Trust Services Criteria, that assesses whether an organisation's controls are suitably designed at a specific point in time. It's the faster of the two SOC 2 report types — Type II additionally tests operating effectiveness over a period — and is often a customer's first SOC 2 milestone before pursuing Type II.
How grComply benefits your SOC 2 Type I programme
Security (CC) plus any Trust Service Category
CC1–CC9 plus Availability, Confidentiality, Processing Integrity, and Privacy sit in one tree — activate only the categories your engagement actually scopes.
Design-of-controls evidence, versioned
Type I only needs point-in-time design evidence; every artefact is versioned so an as-of date is never ambiguous to an examiner.
Auditor-grade engagement workflow built in
Raise observations, respond, countersign, and close — the exact workflow a SOC 2 examination runs on, not a shared drive of screenshots.
Peer review before anything is final
A second reviewer independently countersigns, satisfying the two-person integrity examiners expect from a mature control environment.
Evidence reused across CC and other frameworks
A control satisfying CC6.1 access-control criteria can simultaneously satisfy ISO 27001's A.8.2 or NIST CSF's PR.AA — evidence uploaded once.
Versioned report package at close
A completed engagement produces a versioned audit report package, not a one-off export nobody can trace back to source evidence.
5 TSC series, seeded with real Common Criteria structure
Security (the mandatory Common Criteria) plus the four optional Trust Service Categories — activate only what your specific engagement covers.
Security — Common Criteria (CC)
The mandatory baseline every SOC 2 report includes — CC1 through CC9, covering control environment, communication, risk assessment, monitoring, and control activities.
Availability
Systems are available for operation and use as committed or agreed — relevant when uptime and infrastructure resilience are part of the service commitment.
Confidentiality
Information designated as confidential is protected as committed or agreed — typically scoped in for B2B SaaS handling client-designated confidential data.
Processing Integrity
System processing is complete, valid, accurate, timely, and authorised — relevant for platforms where data processing correctness is the service promise.
Privacy
Personal information is collected, used, retained, disclosed, and disposed of in conformity with the entity's privacy notice — scoped in when PII handling is customer-facing.
Evidence grComply already models for SOC 2 Type I
Real evidence-requirement examples from the seeded control library — the same evidence types every other framework in grComply uses, not a bespoke process for this one.
| Control | Evidence type | Example |
|---|---|---|
| CC6.1 — Logical access controls | IAM export / access review | Identity and access management export showing enforced access-control policy |
| CC7.1 — System monitoring | SIEM log sample | Monitoring/alerting configuration evidence showing anomaly-detection coverage |
| CC1.4 — Board oversight | Policy document | Approved information security policy with governance sign-off |
| A1.2 — Availability commitments | Architecture diagram | Infrastructure resilience/redundancy design evidence |
| P1.1 — Privacy notice | Policy document | Published privacy notice matching actual data-handling practice |
Why this matters: Type I only has to prove design at one point in time — grComply's versioning means the exact control state on your as-of date stays reconstructable, even if the control has changed since, which is precisely what an examiner needs to see.
SOC 2 Type I, in the live workspace
The same grComply workspace shown across the platform — control browser, mapping, evidence, and AI assist apply identically to SOC 2 Type I.
SOC 2 Type I in grComply
What is SOC 2 Type I?
SOC 2 Type I is an AICPA Trust Services Criteria attestation examining whether an organisation's controls are suitably designed at a single point in time — the report's as-of date — rather than tested over a period.
Does grComply support the full SOC 2 Type I structure?
Yes — grComply seeds the complete TSC 2017 structure as a comprehensive library: 5 TSC series, 20 Criteria, and 61 Points of focus, covering Security plus the four optional categories.
Which Trust Service Categories do we need beyond Security?
It depends on your service commitments — Availability if uptime is promised, Confidentiality if you handle client-designated confidential data, Processing Integrity if processing correctness is the service, and Privacy if you handle personal information directly.
How is Type I different from Type II in grComply?
Both share the identical seeded TSC control tree — the difference is evidence period. Type I needs point-in-time design evidence; Type II (see its own page) needs evidence the controls operated effectively across an examination window.
Can SOC 2 evidence also satisfy ISO 27001?
Where controls are genuinely equivalent, yes — cross-framework mapping lets one piece of evidence, like an access-control export for CC6.1, simultaneously credit an ISO 27001 Annex A control.
Does grComply support the peer-review requirement examiners expect?
Yes — a reviewer distinct from the control owner countersigns observations before an engagement closes, and every state change is timestamped and attributed for a full audit trail.
Can we upgrade from Type I to Type II later?
Yes — a tenant already running Type I on the seeded TSC tree can activate Type II on the identical control structure without re-authoring evidence categories.
What does the final report package include?
A versioned audit report package generated from the engagement's actual observations, evidence, and sign-offs — traceable back to source, not a static export. See SOC 2 Type II for the period-based version.
See SOC 2 Type I mapped into your control library
Powered by Mutex Systems. Back to Compliance Frameworks → · grComply overview → · Security Awareness Training →
Talk to us about SOC 2 Type I
Tell us where your SOC 2 Type I programme stands today, and we'll route it to the right product specialist.
- A product specialist replies personally — not a bot
- No obligation after the first conversation
- WhatsApp support also available 24/7
By submitting, you agree to be contacted about your enquiry. We respect your privacy.
Book a meeting directly
Pick a time that works for you — 30 minutes with a product specialist, no sales script.
Ready to bring SOC 2 Type I into one control library?
We respond within one working day — or reach us instantly on WhatsApp.