.svg)
A professional services firm starts its SOC 2 process the same way most companies do. An enterprise client puts it in an RFP. The team subscribes to a GRC platform, engages an auditor, and starts working through controls. Three weeks later, the platform shows 58% compliant. The team cannot tell how much of that score reflects their actual operations.
This is the pattern for every non-SaaS organization that attempts SOC 2 with default tooling. The platform was designed for a different company, and finding the right SOC 2 consultant matters even more when the defaults do not fit. The controls it ships are written for SaaS companies with cloud infrastructure, a production application, and a development team. A consulting firm, an accounting practice, a healthcare services company: none of them fit that template. And the score will mislead you about how close you are until someone does the work the platform cannot do for you.
Why Default GRC Platforms Miss the Mark for Services Firms
Every major GRC platform ships with a control library written for a default tenant. That default is a SaaS company running on AWS or Azure, with a development team pushing code, an application serving customers, and infrastructure to manage. The platform's compliance score measures progress against that profile.
When a professional services firm signs up, the platform still scores against the SaaS default. Controls reference infrastructure diagrams the firm does not have. Tests check for deployment pipelines that do not exist. Evidence requirements assume the company owns and operates the systems where client work happens. A services firm that operates inside client environments hits every one of these walls.
The 58% Problem
The platform score is real. It accurately reflects how many of the platform's default controls have been addressed. But it is scoring the wrong controls against the wrong scope. Some of those controls are irrelevant. Others are missing entirely because the platform does not know what a services firm's actual risk surface looks like. The score had become a proxy for progress in a way that obscured whether progress was actually happening.
This is not a platform failure. GRC platforms are tools, and good ones at that. The failure is treating the out-of-the-box configuration as a compliance roadmap when the company does not match the template.
The AICPA Never Wrote a Checklist
SOC 2 Trust Services Criteria are intentionally principles-based. The AICPA published criteria, not controls. CC1 (Control Environment) describes what an organization's control environment should accomplish. It does not prescribe how. CC6 (Logical and Physical Access) establishes expectations for access management without specifying which tools, processes, or documentation formats satisfy those expectations.
Every control inside a GRC platform is one vendor's interpretation of how a hypothetical company might satisfy the criteria. That interpretation works well when the company matches the hypothesis. It breaks down when the company operates differently.
CC1 and CC6 Translation Challenges
CC1 assumes the entity has a board or oversight body, a defined organizational structure, and internal accountability mechanisms. CC6 expects the entity to manage logical access to systems, provision and deprovision identities, and restrict physical access. A services firm whose consultants work inside client-managed systems needs to translate those criteria to its own context: what does logical access mean when the firm does not own the system?
The criteria still apply. The platform's default controls do not, at least not as shipped.
Scoping Is the Entire Engagement
For a SaaS company, scoping is typically the first week of a multi-month engagement. The boundaries are clear: the application, the infrastructure it runs on, the team that builds and operates it.
For a services firm, scoping is the engagement. Every control needs to be evaluated against the company's actual operations. Some get customized. Some get replaced entirely. Some get marked not applicable with a justified rationale the auditor will accept.
This work requires judgment that a platform cannot automate. It requires someone who understands both the SOC 2 criteria and the services firm's operating model well enough to translate between them.
The Scoping Questions That Matter
What systems does the firm own vs. access? A consulting firm using client-provisioned laptops, client VPNs, and client collaboration tools has a fundamentally different control boundary than a firm with its own infrastructure. The SOC 2 report covers the firm's system, which needs to be defined clearly.
Where does client data live? If client data never touches the firm's systems, the data-handling controls look entirely different. If the firm processes data in its own environment, the full data lifecycle needs controls. This distinction changes the scope dramatically.
What does infrastructure mean for this company? A firm with no servers, no cloud instances, and no production database still has infrastructure: corporate email, file sharing, identity management, endpoint devices. The infrastructure diagram is not empty. It just looks nothing like a SaaS architecture diagram.
Which Trust Services Categories apply? Security is always in scope. Availability, Processing Integrity, Confidentiality, and Privacy may or may not apply depending on what the firm does and what the client expects. Narrowing to Security-only for the first report is a common and defensible choice.
Do Not Chase the Platform Score
A previous referral had positioned the work as something a consultant could knock out in a day. That framing under-describes what scoping a non-default SOC 2 actually requires. The firms that struggle are the ones that skip scoping and jump straight into raising the platform score to 100. The score is not the objective. A clean SOC 2 report against a properly scoped system is the objective.
The Controls That Actually Matter for Services Firms
Once scoping establishes the boundaries, the control set for a services firm typically centers on different priorities than a SaaS company.
| Control Area | SaaS Focus | Services Firm Focus |
| Access Management | Production databases, application access | Corporate systems: email, file sharing, client portals |
| Personnel Security | Standard onboarding/offboarding | Primary control area: background checks, NDAs, role definitions |
| Change Management | Code deployments, infrastructure changes | Policy updates, tool configurations, process changes |
| Vendor Management | Third-party SaaS tools | The firm is the third party, responsibilities need clear definition |
| Physical Security | Cloud provider inherits most controls | Depends on where work happens: office, remote, client site |
Negotiating the Right Report Type
Services firms facing tight deadlines should consider whether a Type 1 report on an accelerated timeline meets the immediate requirement. Type 1 attests that controls are designed and in place at a point in time. Type 2 attests that controls operated effectively over an observation period, typically six to twelve months.
The Type 1 First Strategy
Many enterprise clients will accept a Type 1 now with a contractual commitment to Type 2 within twelve months. This is a common and usually receptive ask, but most services firms do not know to make it. The strategic sequence: complete a Type 1 to unblock the deal, then start the Type 2 observation period immediately.
What the Path Forward Looks Like
A services firm approaching SOC 2 should expect the engagement to follow this pattern:
- Scoping workshop to define the system boundary, identify which TSC categories apply, and inventory the firm's actual technology and process landscape
- Gap assessment against the scoped criteria, not against a default control library, identifying what exists, what needs to be built, and what is not applicable
- Control design and implementation for the gaps, right-sized to the firm's operations, with documentation that explains rationale and maps to TSC
- Auditor alignment to confirm the scope and approach before the examination begins, reducing the risk of scope disagreements during fieldwork
- Type 1 examination against the defined scope, followed by the start of the Type 2 observation period
SOC 2 Scoping for Services Firms
Find out where your security program stands before committing to an audit timeline.
SOC 2 was designed to be flexible enough to apply to any service organization, not just software companies. But the ecosystem of platforms, templates, and accelerators that has grown around it optimizes for one company type. Services firms that recognize this early invest their time in scoping, not in chasing a compliance score that measures the wrong things.
Frequently Asked Questions
Can a professional services firm get SOC 2 certified without owning infrastructure?
Yes. SOC 2 applies to the firm's system, which is defined during scoping. A services firm that uses corporate email, file sharing, identity management, and endpoint devices has a system, even without servers or cloud instances. The infrastructure diagram looks different from a SaaS company, but it is not empty. The scope focuses on the firm's actual technology and process landscape.
Why does my GRC platform score not match my audit readiness?
GRC platforms ship with control libraries written for a default SaaS company. When a non-SaaS organization uses the platform, the score measures progress against controls that may not apply. Some controls are irrelevant, and others the firm needs are missing from the default library. The score needs to be re-evaluated against a properly scoped control set that reflects the firm's actual operations.
Should a services firm start with SOC 2 Type 1 or Type 2?
Type 1 is typically the right starting point for services firms with tight deadlines. It attests that controls are designed and in place at a point in time, which satisfies most enterprise procurement requirements. The Type 2 observation period starts immediately after, building the operational track record needed for the Type 2 report within 6 to 12 months.
What SOC 2 Trust Services Categories apply to professional services firms?
Security (Common Criteria) is always in scope. Availability applies if the firm provides services with uptime commitments. Confidentiality applies if the firm handles sensitive client data. Processing Integrity applies if the firm processes transactions or data on behalf of clients. Narrowing to Security-only for the first report is a common and defensible approach that simplifies the initial engagement.
How long does SOC 2 take for a services firm?
The timeline depends on the firm's current security maturity and scope complexity. Firms with existing security practices (access management, documented policies, endpoint protection) can reach Type 1 readiness in 8 to 14 weeks with consultant support. Firms building from informal practices should plan for 4 to 6 months. The scoping phase is proportionally larger for services firms than for SaaS companies.
Ready to Start Your Compliance Journey?
Get a clear, actionable roadmap with our readiness assessment.
About the Author
Former security architect for Bank of Canada and Payments Canada. 20+ years building compliance programs for critical infrastructure.
How Ready Are You for SOC 2?
Score your security program in under 5 minutes. Free.
Take the Scorecard