SOC 2 Type II certification has become a standard procurement requirement for enterprise software, and enterprise PSA is no exception. For a platform that holds time entry data, billing records, rate cards, project margins, resource allocations, and GL-adjacent financial transactions for hundreds of people at once, the security posture of the PSA vendor is a material business risk — not just an IT checkbox. This article explains what SOC 2 Type II actually covers in the PSA context, what the certificate does and does not tell you about a vendor’s security practices, and what surrounding controls to evaluate alongside the certification during your procurement review.
What SOC 2 Type II Actually Covers
SOC 2 is a framework published by the AICPA (American Institute of Certified Public Accountants) that evaluates the security, availability, processing integrity, confidentiality, and privacy controls of a service organization. Type I is a point-in-time assessment — an auditor reviews whether the controls are designed correctly at a specific date. Type II is the operationally meaningful certification: an auditor observes whether those controls function as designed over a sustained observation period, typically six to twelve months. When enterprise procurement requires SOC 2 Type II, they are asking for evidence that the vendor’s security controls work consistently in practice, not just that they were correctly described on paper at the time of audit.
The five Trust Service Criteria are not equally weighted for PSA evaluation purposes. Security — covering logical and physical access controls, change management, and incident response — is the primary criterion for a platform that holds financial and personnel data. Availability covers whether the system meets uptime commitments, which matters for a PSA used in billing and month-end close operations. Confidentiality covers how the vendor protects data that is classified as confidential by the customer. Integrity and Privacy are relevant but less frequently the focus of enterprise PSA procurement reviews.
What SOC 2 Type II Means Specifically for PSA
Enterprise PSA platforms hold data that sits at the intersection of employment records, financial records, and client confidential information. Time entries reflect individual consultant activity and billable hours that appear on client invoices. Rate cards contain proprietary pricing information. Project margin data is commercially sensitive. GL-mapped billing transactions are financial records that auditors may request. A PSA vendor’s SOC 2 Type II report covers whether the controls protecting all of this data meet the standards the auditor evaluated — but the scope of what is covered depends on what the vendor included in the audit boundary.
This is the most important nuance in SOC 2 evaluation: the audit boundary. A vendor can hold a SOC 2 Type II certificate that covers only their production application environment, while their development environment, third-party subprocessors, or data backup infrastructure sit outside the audit scope. When requesting the SOC 2 report — which should be available under NDA — read the system description section carefully. It will specify exactly what infrastructure, services, and processes the auditor evaluated. Anything outside that boundary is not covered by the certification, regardless of what the vendor’s security page claims.
Security Controls That Matter Beyond the Certificate
SOC 2 Type II establishes a baseline. It tells you the vendor has functioning controls at audit time, evaluated by a qualified third party. What it does not tell you is how the vendor’s security posture compares to alternatives, what their incident response process looks like in practice, or whether their data handling practices align with your firm’s specific requirements. The controls that matter most for enterprise PSA procurement extend beyond the certificate in three areas.
Penetration testing cadence and scope: leading PSA vendors conduct annual or more frequent penetration tests by qualified external firms, with scope covering the application, APIs, and infrastructure. Ask for the executive summary of the most recent penetration test, or at minimum ask when it was conducted, by whom, and whether critical or high findings were remediated before the current version was deployed. A vendor that cannot confirm regular external penetration testing is relying entirely on the SOC 2 audit for security assurance, which is not sufficient for a platform holding financial and personnel data at enterprise scale.
Subprocessor transparency: enterprise PSA vendors rely on subprocessors — cloud infrastructure providers, email delivery services, support platforms, backup systems — that handle customer data on their behalf. A complete subprocessor list, updated when changes occur and available on request, is the baseline expectation for enterprise security review. Vendors that cannot provide this list or that require legal pressure to disclose their subprocessors create due diligence risk that procurement teams will flag.
Example: A 260-person IT consulting firm runs enterprise PSA procurement through a security review that requires SOC 2 Type II, a current penetration test summary, a complete subprocessor list, and responses to a 40-question security questionnaire. Three of the four PSA vendors being evaluated provide the SOC 2 report readily. Two provide the penetration test summary. One declines to provide the subprocessor list without an NDA in place. The security team uses these responses — not just the certificate — to rank the vendors on security posture.
Identity, Access, and SSO as Security Controls
Beyond the SOC 2 certificate, the identity and access management capabilities of the PSA itself are a security control the firm’s IT team will evaluate. The baseline expectation at enterprise scale is SAML 2.0-based single sign-on, which allows the PSA to delegate authentication to the firm’s existing identity provider — Okta, Microsoft Entra ID (formerly Azure AD), ADFS, OneLogin — rather than maintaining a separate credential store. SSO integration means that when an employee’s account is deprovisioned in the identity provider, their PSA access is revoked automatically rather than requiring a separate manual step that might be delayed or overlooked.
Role-based access control within the PSA — governing which users can see which data at the cost center, engagement, and financial object level — is the second layer of the identity posture. A PSA that supports SSO but allows all authenticated users to view all financial data regardless of role is not a secure deployment at enterprise scale. The permission model needs to be granular enough that a project manager can see their own project’s margin without accessing the firm’s full rate card, and that a billing administrator can create invoices without accessing resource cost rates. The cost center-based permission hierarchy, when correctly configured, provides this granularity. During security review, ask for a demonstration of the permission model against a realistic org chart scenario rather than accepting a feature description at face value.
Data Residency, Encryption, and Retention
Three data handling questions are standard in enterprise PSA security reviews and should be answered in writing, not verbally during a demo.
- Data residency: where is customer data stored geographically, and can the vendor commit to keeping it within a specified jurisdiction? For firms operating under GDPR, data stored on US infrastructure by a US vendor without standard contractual clauses or equivalent mechanisms creates compliance risk. Ask specifically about primary storage, backup storage, and disaster recovery replication — all three locations are relevant to residency.
- Encryption: the standard expectation is encryption at rest (AES-256 or equivalent) and in transit (TLS 1.2 or higher). Ask specifically whether encryption keys are managed by the vendor, by a third-party key management service, or by the customer — and whether customer-managed encryption keys are available at the enterprise tier.
- Retention and deletion: when a customer offboards, how long does the vendor retain the data, in what form, and what is the deletion verification process? PSA data includes financial records that the firm may need to retain for audit purposes after contract termination. Verify that the vendor’s retention policy gives the firm enough time to extract and archive necessary records before deletion.
How to Verify Security Claims During Evaluation
Security claims on vendor marketing pages are not evidence. The procurement process for an enterprise PSA should include a formal security review that produces documented, verified responses rather than verbal assurances. Four artifacts are the minimum for a credible security evaluation.
First, the SOC 2 Type II report itself, under NDA, with the most recent audit period ending within the last twelve months. Read the system description to understand the audit boundary and the exceptions section to understand what the auditor found and how the vendor responded. Second, a current penetration test executive summary from a named external firm, confirming the test date, scope, and remediation status of identified findings. Third, a complete subprocessor list, current as of the evaluation date. Fourth, a completed security questionnaire using the firm’s standard template or a recognized framework such as the CAIQ (Consensus Assessments Initiative Questionnaire) from the Cloud Security Alliance.
Vendors that are genuinely prepared for enterprise security review will have these artifacts readily available and will respond to questionnaires within a reasonable timeframe without escalating to legal or requiring special commercial arrangements before sharing. The speed and completeness of a vendor’s security review response is itself a signal about how seriously they treat enterprise security obligations — and how that experience will translate into their incident response behaviour if a security event ever occurs.
