SOC 2 Attestation Services
SC US performs independent SOC 2 examinations for technology companies and service organizations that need to demonstrate the effectiveness of their security and operational controls.
Our auditors evaluate controls against the AICPA Trust Services Criteria and issue formal reports for customers, partners, investors and other authorized users.
Independent assurance for organizations that handle customer data
Customers and enterprise buyers increasingly expect evidence that the systems supporting their services are secure, reliable and properly controlled.
A SOC 2 report provides that evidence. It describes the system being examined, the controls management has implemented and the results of an independent CPA examination.
Specialist assurance depth without the unnecessary burden of a traditional engagement
A strong SOC 2 attestation engagement should provide independent assurance while keeping the internal effort organized. Our approach combines technical rigor, senior involvement and a clear evidence process so your team can complete the examination without losing sight of day-to-day operations.
The cost most teams miss
Internal time can become the larger burden when scope is too broad, evidence requests are unclear or responsibilities are not organized before fieldwork begins.
The objective is not to reduce examination rigor. It is to eliminate avoidable effort around the attestation.
How SC US reduces the burden
We organize the engagement so the work is technically rigorous, easy to coordinate and clear to both technical and non-technical stakeholders.
Senior professionals remain involved from scoping and planning through fieldwork, technical review and report issuance. Questions are addressed by people who understand both the reporting framework and the environment being examined.
SC US works alongside SAV Associates Professional Corporation, an independent Ontario CPA firm with an active registration and Certificate of Authorization. Our SOC 2 reports are supported by technical expertise, independence and disciplined execution.
Our assurance professionals bring Big Four experience while working with the speed, accessibility and personal involvement of a boutique firm. You receive practical guidance and direct attention that larger delivery models often struggle to provide.
Our partner contributed to the CPA Canada and AICPA SOC 2 guide, our SOC 1 work is used in University of Toronto teaching materials, and our cybersecurity thought leadership has appeared through AICPA, The Wall Street Journal and Forbes. .
Coordinate SOC 2 and ISO 27001 without duplicating the same work
SOC 2 and ISO 27001 remain separate engagements, but many controls and evidence sources overlap. A coordinated approach identifies those overlaps early while preserving the requirements, procedures and reporting of each framework.
Independent attestation against the Trust Services Criteria.
Common evidence can be organized once and coordinated across both engagements.
Assessment of the information security management system.
Shared controls and evidence are identified before requests begin.
Schedules, requests and communication are aligned.
Administrative duplication is reduced, not the required examination or certification work.
A detailed assurance report, not a certificate
A SOC 2 report is an independent assurance report on the controls of a service organization. The examination is performed against the AICPA Trust Services Criteria.
The report explains the services and systems included in scope, the controls management has implemented, the procedures performed by the auditor, the results of those procedures and the independent auditor's conclusion.
Organizations commonly use the report during customer security reviews, enterprise procurement, vendor due diligence and other situations where stakeholders need independent assurance over the control environment.
Type I and Type II answer different assurance questions. The visual below shows the practical progression rather than forcing the reader through a dense comparison table.
A point-in-time examination of control design and implementation as of a specified date.
An examination of control design and operating effectiveness throughout a defined observation period.
What a SOC 2 report evaluates
A SOC 2 report evaluates controls relevant to the AICPA Trust Services Criteria. Security is included in every engagement. The other categories are added only where they match your product, commitments and customer expectations.
Protection against unauthorized access, use or modification of systems and information.
Systems are available for operation and use in accordance with customer commitments.
Processing is complete, valid, accurate, timely and authorized.
Information designated as confidential is protected in accordance with commitments.
Personal information is collected, used, retained, disclosed and disposed of in line with commitments.
Evaluates whether controls are suitably designed as of a specific date.
Evaluates whether controls were suitably designed and operated effectively throughout a defined period.
SOC 2 services structured around where your organization is today
Some organizations are preparing for their first report. Others are moving into Type II, maintaining an annual cycle or changing auditors. We shape the examination around the assurance your customers need next.
Establish the right scope, document the control environment and prepare for a credible first examination.
Build on the documented control environment and demonstrate that controls operated effectively over the observation period.
Maintain reporting continuity while making the annual process more structured and predictable.
A SOC 2 attestation is an independent examination of a service organization’s controls against the AICPA Trust Services Criteria.
The examination evaluates controls related to Security and, where relevant, Availability, Processing Integrity, Confidentiality and Privacy. The auditor reviews the organization’s system description, control design and supporting evidence before issuing an independent SOC 2 report.
A Type I examination evaluates control design as of a specified date. A Type II examination also evaluates whether the controls operated effectively throughout a defined period.
SOC 2 reports are commonly requested from organizations that store, process, transmit or otherwise manage customer information as part of the services they provide.
They are particularly relevant to SaaS companies, cloud-service providers, managed service providers, data-processing organizations, FinTech and HealthTech companies, business-process outsourcing providers, and technology vendors selling to enterprise customers.
A SOC 2 report may be required by a customer contract, procurement team, investor, business partner or another stakeholder seeking independent assurance over the organization’s controls.
A SOC 2 Type I report evaluates whether controls are suitably designed and implemented as of a specific date.
A SOC 2 Type II report evaluates both the design of the controls and whether those controls operated effectively throughout a defined observation period.
Type I is often used by organizations completing their first SOC 2 examination or responding to an immediate customer requirement. Type II provides stronger assurance because it includes testing over time and shows whether controls were consistently performed.
Not necessarily.
A Type I report can be useful when an organization is new to SOC 2, has recently implemented its controls or needs an independent report within a shorter commercial timeline. It establishes whether the controls are suitably designed as of a specified date.
An organization may proceed directly to Type II when its controls are already established, have been operating consistently and sufficient evidence is available throughout the proposed observation period.
The right path depends on customer requirements, control maturity, evidence availability, the reporting deadline and whether stakeholders specifically require Type II assurance.
Every SOC 2 examination includes the Security category.
Availability, Processing Integrity, Confidentiality and Privacy are added where they are relevant to the organization’s services, contractual commitments and risk environment.
The criteria should not be selected simply because broader coverage appears more impressive. Adding unnecessary criteria increases the scope, control requirements and evidence burden of the examination.
Selection should consider customer expectations, service commitments, the information handled, availability obligations, processing responsibilities and privacy requirements.
Security addresses protection against unauthorized access, misuse, damage and other security events. Typical areas include access management, monitoring, vulnerability management, incident response, risk assessment and change management.
Availability addresses whether systems and information are accessible and operational in accordance with commitments. Typical areas include monitoring, backups, disaster recovery, business continuity and capacity management.
Processing Integrity addresses whether system processing is complete, valid, accurate, timely and authorized.
Confidentiality addresses protection of information designated as confidential, including classification, access restrictions, encryption, retention and disposal.
Privacy addresses the collection, use, retention, disclosure and disposal of personal information in accordance with privacy commitments.
A Type II report covers a defined period rather than a single date.
The appropriate observation period depends on customer expectations, the maturity of the control environment and the organization’s reporting objectives. First-time Type II reports may cover a shorter period, while established annual reporting programs commonly cover a longer period.
Before the observation period begins, controls should be fully implemented, control owners should understand their responsibilities, required activities should occur at the correct frequency and supporting evidence should be retained consistently.
The timeline depends on the report type, systems and services in scope, selected Trust Services Criteria, number and complexity of controls, readiness of the system description, quality of supporting evidence and responsiveness of the organization.
A Type I examination can generally proceed once controls are implemented and ready for testing. A Type II engagement also includes an observation period during which the controls must operate.
The project timeline should distinguish between readiness work, the observation period, examination fieldwork, review and final report preparation.
The evidence depends on the controls included in the examination.
Common examples include policies and procedures, access approvals, access-review records, onboarding and termination records, security training records, vulnerability scans, penetration-test reports, change tickets, incident records, backup and recovery records, vendor reviews, risk assessments, monitoring reports and management-review records.
For a Type II examination, the auditor selects evidence from throughout the observation period. The evidence should show that the control occurred, who performed it, when it occurred, what was reviewed and how any issues were resolved.
A SOC 2 report generally includes management’s assertion, the independent auditor’s report, management’s description of the system, the applicable Trust Services Criteria, the controls included in the examination and, for a Type II report, the auditor’s tests and results.
The system description explains the services, infrastructure, software, people, procedures and data included in the examination.
The auditor’s opinion addresses whether the description is fairly presented and whether the controls were suitably designed. For Type II, the opinion also addresses whether the controls operated effectively throughout the specified period.
The scope should include the system used to provide the services relevant to the report.
This may include production applications, cloud infrastructure, databases, identity and access-management platforms, software-development and deployment processes, security-monitoring tools, supporting personnel, relevant locations and third-party services.
The boundary should be broad enough to address the services and commitments customers rely on, but not so broad that unrelated systems and business activities are unnecessarily included.
A subservice organization is a third party that performs services or controls relevant to the system being examined.
Examples may include cloud-hosting providers, data-center operators, payment processors, managed-security providers, customer-support platforms and outsourced infrastructure providers.
Management must determine how relevant subservice organizations are addressed in the report. Depending on the reporting approach, their controls may be excluded and addressed through complementary controls, or included as part of the broader system description and examination.
Complementary user entity controls are controls that customers or users of the service are expected to implement for the service organization’s controls to achieve the applicable criteria.
For example, the service organization may provide configurable access controls, while the customer remains responsible for assigning appropriate access, reviewing its own users, protecting credentials, configuring security settings and notifying the service organization of terminated users.
These responsibilities are described in the SOC 2 report so customers understand which controls remain their responsibility.
An exception occurs when testing shows that a control did not operate as described or that the available evidence did not support the control’s operation.
An exception does not automatically result in a modified opinion. The auditor evaluates its nature, frequency, cause, affected population, any compensating controls and its effect on the applicable Trust Services Criteria.
For a Type II report, relevant exceptions and management’s response may be included in the control-testing section. Potential exceptions should be discussed during the engagement rather than first appearing when the draft report is issued.
SC US can explain SOC 2 requirements, provide general observations and perform permitted readiness activities while maintaining the independence required for the attestation engagement.
Management remains responsible for designing and implementing controls, selecting the system and criteria in scope, preparing the system description, operating the controls, evaluating gaps and making management’s assertion.
The auditor cannot assume management’s responsibilities or design the control environment on management’s behalf. Where broader implementation assistance is required, responsibilities must be structured carefully to preserve independence.
Yes. SOC 2 and ISO 27001 are separate frameworks, but many underlying controls and evidence requirements overlap.
Shared areas commonly include risk assessment, access management, incident response, change management, vendor oversight, vulnerability management, business continuity, security monitoring and policy management.
A coordinated approach can align evidence requests, schedules and control mapping so the organization does not repeatedly provide the same support. Each engagement still requires its own scope, procedures, conclusions and reporting.
A SOC 2 report is generally a restricted-use report.
It is intended for management, customers, prospective customers, business partners and other authorized users who understand the nature of the service and the controls described in the report.
Organizations commonly provide the report under a nondisclosure agreement or through a controlled trust portal. A SOC 3 report is designed for broader distribution and does not include the same detailed system description, controls, tests and results.
There is no single universal expiration date stated on a SOC 2 report.
Customers commonly expect an updated report annually. They may also request a bridge letter covering the period between the end date of the most recent report and the current date.
Whether a report remains acceptable depends on the report period, customer requirements, changes to the system or control environment, elapsed time and whether significant incidents or control changes occurred.
Consider whether the firm is appropriately licensed to issue the report, its SOC 2 and technology-assurance experience, familiarity with SaaS and cloud environments, access to senior professionals, attestation-planning approach, communication during fieldwork, expected timelines and experience coordinating SOC 2 with ISO 27001 or other frameworks.
The decision should not be based on price or promised speed alone. A SOC 2 report is an independent assurance product that customers may rely on when evaluating the organization’s control environment.
Be prepared to discuss the products and services to be included, the legal entity that will issue the report, whether Type I or Type II is required, the desired report date, customer or contractual requirements, proposed Trust Services Criteria, technology environment, major service providers, current state of policies and controls, and whether related ISO 27001 work is planned.
SC US uses this information to define the scope, expected timeline and level of effort for the engagement.
Start your SOC 2 attestation
Tell us whether you are pursuing Type I, Type II or are still determining the right approach. We will discuss your customer requirements, current control environment and proposed reporting timeline.
Your inquiry has been captured in this prototype. Connect the form to your CRM or email workflow before launch.