Enterprise PSA FAQ Category: Governance, Security & Compliance

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.

Identity and access management in enterprise PSA is more demanding than in most enterprise software categories because the data the PSA holds is sensitive across multiple dimensions simultaneously. Time entries reveal individual consultant activity. Rate cards contain proprietary pricing. Project margin data is commercially confidential. GL-adjacent billing records are financial records subject to audit. A PSA that allows all authenticated users to see all of this data — or that manages credentials independently of the firm’s identity provider — creates security and governance risk that IT and finance teams will both flag during procurement. This article explains how SSO, SAML, and role-based access control work in enterprise PSA, and what distinguishes a permission model that actually governs financial data access at scale from one that provides the appearance of access control without the substance.

SSO and SAML: How Authentication Works in Enterprise PSA

Single sign-on allows users to authenticate once through a central identity provider and then access multiple systems — including the PSA — without entering separate credentials for each. In enterprise environments, SSO is not primarily a convenience feature. It is a security control: it means the PSA does not maintain its own credential store, which eliminates a category of risk (compromised PSA-specific passwords, orphaned accounts after employee departure) and centralizes authentication management in the IT team’s existing infrastructure.

SAML 2.0 (Security Assertion Markup Language) is the protocol that most enterprise identity providers use to communicate authentication decisions to service providers like the PSA. When a user attempts to access the PSA, the PSA redirects the authentication request to the identity provider. The identity provider validates the user’s credentials — through password, multi-factor authentication, or device certificate, depending on the firm’s policy — and issues a signed assertion back to the PSA confirming the user’s identity and, optionally, their group memberships and attributes. The PSA trusts that assertion without ever seeing or storing the user’s password. Any identity provider that supports SAML 2.0 is compatible with this pattern, which covers Okta, Microsoft Entra ID (formerly Azure AD), ADFS, OneLogin, Ping Identity, and most other enterprise identity platforms in common use.

Identity Provider Compatibility and Configuration Depth

SAML 2.0 support is the baseline, but the configuration depth available within that standard varies between PSA platforms and matters for enterprise deployments. The questions that reveal configuration depth go beyond “do you support SAML 2.0” — all serious enterprise PSA platforms do — to how the platform handles SAML assertions in practice.

Attribute mapping is the first depth indicator. When the identity provider issues a SAML assertion, it can include attributes beyond the user’s identity: group memberships, department, location, employment type. A PSA that can consume those attributes and use them to automatically assign the correct role and cost center access to the user — without requiring a PSA administrator to manually configure each new user — scales to a 300-person firm without becoming an administrative burden. A PSA that requires manual role assignment after every SSO login does not.

Just-in-time provisioning is the second depth indicator. When a user authenticates via SAML for the first time and no PSA account exists, the platform can either reject the authentication or automatically create an account with default permissions derived from the SAML assertion. Just-in-time provisioning is what allows new joiners to access the PSA immediately on their first day without an IT ticket to create a PSA account. Without it, every new employee requires a separate provisioning step in the PSA that IT must complete before the employee can log in.

Role-Based Access Control: What It Means in the PSA Context

Role-based access control (RBAC) is the principle that a user’s access to data and operations is determined by their role in the organization, not by individual configuration. In most enterprise software, roles map to functional job types — administrator, manager, user — and the permissions attached to each role are fixed by the vendor. Enterprise PSA access control is more complex because the relevant dimensions are not just functional roles but also the organizational scope of those roles.

A resource manager at a 300-person firm should be able to see utilization data and resource allocations for consultants in their practice, but not in other practices. A billing coordinator should be able to create invoices for their assigned client portfolio, but not view the margin data behind those invoices. A finance director should have read access to all financial data across cost centers, but not be able to modify billing rules. These access patterns require a permission model that combines role-based functional permissions (what operations can this user perform?) with data-scoped organizational permissions (on which cost centers and engagements does this role apply?). A flat role model — where all billing coordinators see all client data or all resource managers see all utilization data — does not serve a firm where different practices operate independently and confidentiality between them matters.

The Two-Tier Permission Architecture

Enterprise PSA platforms handle this complexity through a two-tier permission architecture that separates system-wide permissions from data-scoped permissions.

System-wide permissions (sometimes called global permissions) control access to features that affect the entire platform: the ability to configure system settings, manage currencies and exchange rates, maintain the cost center hierarchy, administer user permissions, and run system-level reports. These permissions are granted sparingly because they carry elevated risk — a user with permission to modify the cost center structure can potentially rearrange the hierarchy in ways that grant themselves access to data they were not intended to see. System-wide permissions are typically held by a small number of administrators and the finance team leads who own specific system-level configurations.

Data-scoped permissions (cost center permissions) control what a user can see and do within specific parts of the organizational hierarchy. These permissions are granted at a node in the cost center tree and inherited downward: a user with a permission at the European regional level inherits that permission across all practices and entities beneath it, without requiring individual configuration for each child cost center. Two types of data-scoped permissions exist: action-based (what operations can the user perform — create engagements, maintain billing rates, approve timesheets) and data-based (what cost center data can the user see when running reports, independent of what operations they can perform). The separation matters because a user might need to run consolidated reports across cost centers they cannot operationally modify.

Governing Access to Financial Data Specifically

The most governance-sensitive data in a PSA is financial: rate cards, cost rates, project margin, billing configurations, and the GL-mapped transaction records that feed the ERP. At enterprise scale, the principle of least privilege — granting each user access only to the financial data their role requires — is both a security requirement and an operational one. When too many users can see cost rates, sensitive compensation-adjacent data spreads beyond the HR and finance perimeter. When too many users can modify billing rules, invoice accuracy depends on trusting every one of those users to configure correctly.

Example: A 320-person consulting firm configures PSA permissions so that project managers can view their own project’s budget versus actuals but cannot see the underlying cost rates used to calculate margin. Finance directors can see all financial data across all cost centers but cannot modify billing rules — that permission is limited to the billing administration team. Resource managers can view utilization data across their practice but cannot see individual consultant cost rates. The permission model is configured once at each level of the cost center tree and inherited downward, requiring no per-user configuration for the 260 consultants and project managers in the firm.

The configuration risk in financial data governance is privilege escalation — a user who can modify the permission model can grant themselves access they were not intended to have. Enterprise PSA platforms address this by making the “Users & Permissions” administrative capability itself a separately controlled global permission, and by maintaining an audit log of permission changes so that IT administrators can review any changes to the access model after the fact.

User Provisioning and Deprovisioning at Scale

At 300 people, manual user provisioning in the PSA becomes a meaningful IT burden. SCIM (System for Cross-domain Identity Management) is the protocol that automates this: when the identity provider creates a new user, updates their attributes, or deactivates their account, SCIM pushes those changes to connected applications — including the PSA — automatically. The result is that onboarding a new consultant involves one action in the HR system or identity provider, and the PSA account is created with the correct roles and cost center assignments derived from the user’s department and job title, without an IT ticket.

• Deprovisioning: when an employee leaves, their PSA account should be deactivated on the same day their identity provider account is deprovisioned — not when someone remembers to check the PSA user list. SCIM-based deprovisioning makes this automatic. SSO-only (without SCIM) means the account is effectively inaccessible because the user cannot authenticate, but the account remains in the PSA and appears in user lists, resource scheduling, and reporting until manually removed.
• Role changes: when a consultant is promoted or moves to a different practice, their PSA access should update to reflect their new organizational position. SCIM-based attribute sync means those changes propagate from the identity provider to the PSA automatically. Without SCIM, a practice manager who moves to a different practice may retain their old practice’s data access for weeks or months until an administrator notices.
• Audit trail: every access change — account creation, role modification, permission update, deprovisioning — should be recorded in a tamper-resistant log that compliance and security teams can query. When a SOC 2 auditor asks for evidence of access control effectiveness, the provisioning log is the primary artifact.

Questions That Reveal Access Control Maturity

Three questions move PSA access control evaluation from feature claims to operational evidence. Ask them in sequence during the security and IT evaluation phase, not the functional demo phase.

First: show us a new user being provisioned via SAML just-in-time provisioning with automatic role and cost center assignment derived from identity provider attributes. This single scenario tests SSO depth, attribute mapping, and automatic role assignment simultaneously. A vendor who cannot demonstrate this in a live environment is relying on manual provisioning regardless of what their feature list claims.

Second: what happens in the PSA when a user’s identity provider account is disabled? The correct answer is immediate loss of PSA access — either through SCIM-triggered deprovisioning or through SAML authentication failure at the next session renewal. If the answer is “the PSA account remains active until manually deactivated,” ask how that manual step is tracked and what the average lag is between identity provider deprovisioning and PSA deprovisioning. The lag is your orphaned account risk.

Third: walk us through the permission model for a user who changes roles within the organization — for example, a project manager who becomes a practice lead. Specifically, how are the old permissions removed and the new ones applied, who performs that action, and is the change logged? This tests whether the RBAC model supports controlled role transitions or whether role changes accumulate permissions over time rather than replacing them.

Audit trail requirements in enterprise PSA come from multiple directions simultaneously. Finance needs to reconstruct billing decisions during client disputes. Compliance needs to demonstrate that billing configurations were not changed without authorization during a SOC 2 audit. Legal needs to respond to contract audit rights with timestamped evidence of what rate was applied to which engagement and when. The ERP team needs to trace a GL posting back to the PSA record that generated it. Each of these is a different audit requirement, covering different data, at different retention horizons, with different access controls on the log itself. Understanding which of these the PSA supports natively — and which require supplementary controls — is what makes an audit trail evaluation substantive rather than a yes/no checkbox.

What Audit Trails Need to Cover in Enterprise PSA

A complete audit trail requirement in enterprise PSA spans four distinct categories of events. Most PSA platforms address some of these and not others, and the gaps matter depending on the firm’s specific regulatory and contractual obligations.

The first category is financial record changes: modifications to time entries after submission, expense adjustments, invoice edits, write-downs, and billing adjustments. These are the records most likely to be reviewed during a client dispute or billing audit, and they are the ones where the distinction between who changed what, from what value, to what value, at what time matters most. A system that records only the current state of a financial record — without preserving the prior state and the identity of the user who changed it — is a system that cannot produce a billing audit trail.

The second category is billing configuration changes: modifications to rate cards, billing rules, contract line items, and engagement billing settings. These changes do not affect a single transaction — they affect every transaction that follows. A rate card change that goes unlogged means that if an invoice is disputed three months later, finance cannot demonstrate when the rate changed or who authorized it. At enterprise scale, with dozens of active engagements and multiple billing coordinators maintaining rate configurations, an unlogged billing configuration change is an audit risk that materializes slowly but with large consequences.

The third category is integration transaction history: the record of what was sent to the ERP, when it was sent, in what state, and what happened to it. The fourth is access and permission changes: who modified whose permissions, when, and what the change was.

Financial Record Audit Trail: The Core Requirement

Time entry is the foundational financial record in a PSA. Every billable hour logged becomes a potential billing event, and the audit trail on that record needs to answer a precise set of questions when a dispute arises: who submitted the entry, when, against which project and task type, at which rate, was it approved by whom and when, was it subsequently modified, by whom, from what value, and did it appear on an invoice?

Enterprise PSA platforms handle this through a combination of submission workflow (time entry requires submission and approval before it can be billed, creating a timestamped record of each stage), modification logging (changes to approved time entries are recorded with the original value, the new value, the user who made the change, and the timestamp), and invoice attachment (each invoice line is traceable back to the time entries or milestones that generated it). When a client disputes an invoice line, finance should be able to produce a complete chain of evidence from the original time entry through approval, billing, and invoice generation without assembling it from multiple systems.

Billing Configuration Change History

Billing configuration audit trail is where many PSA platforms fall short. Rate cards, billing rules, and contract terms are typically maintained by a small number of administrators, and changes to them are treated as configuration management rather than financial record changes. The practical consequence is that billing configuration changes are often reversible without trace — an administrator can update a rate, discover the update was wrong, correct it, and the history of the incorrect rate may be lost entirely.

Example: A 290-person IT consulting firm is audited by a client who believes they were overbilled over a six-month period. The dispute centers on whether the correct blended rate was applied to a specific engagement. The billing coordinator believes the rate was correct throughout. The client believes a higher rate was applied for three months before being corrected. Without a timestamped rate card change history, the firm cannot demonstrate that the engagement billing configuration was continuous — the rate either was or was not changed, and neither party can prove it. With an audit trail, the firm produces a log showing the rate card as it was configured on each billing date, with the identity of anyone who modified it and when.

The distinction that matters in billing configuration audit trail is between a change log and a version history. A change log records that a change occurred. A version history preserves the prior state so that finance can reconstruct what any configuration looked like at any point in the past. For billing dispute resolution, version history is the requirement — the log that a change occurred is useful, but the log that shows what was in effect on the billing date of a disputed invoice is what resolves the dispute.

Integration Transaction Audit Trail

Every transaction that the PSA sends to the ERP — AR entries, AP entries, GL journal entries — carries a status that tracks its transmission lifecycle and a cross-reference number that links it to the originating PSA record. The audit trail on these transactions needs to cover whether the transaction was transmitted successfully, whether it was modified after transmission (via integration override), who made the modification, and what the corrected mapping was.

This matters for two audiences. Finance needs it for reconciliation: when an ERP GL entry does not match the PSA record, the integration transaction log is what identifies whether the discrepancy originated in the PSA, in transmission, or in a post-transmission override. Auditors need it for completeness: a SOC 2 auditor reviewing financial reporting controls will ask whether there is a documented record of all transactions sent from the PSA to the ERP, and whether any post-transmission modifications are logged with appropriate authorization. A PSA that allows integration overrides without audit trail creates a control gap that a competent auditor will identify.

Access and Permission Change Logs

The permission model in enterprise PSA is itself a financial control — it determines who can see and modify billing rates, approve time entries, create invoices, and override accounting period settings. Changes to that permission model are therefore financial record events, not just system administration events. When a user’s billing rule access is elevated, or a cost center permission is expanded, or a new user type is granted access to financial configuration, those changes should be logged with the same rigor as financial record changes: who made the change, when, what the prior state was, and what authorization existed for the change.

Access log requirements at enterprise scale go beyond what most PSA platforms provide natively. The audit trail most platforms maintain covers direct user permission changes — who updated whose permissions at what time. What they typically do not cover is indirect access change: a user who gains additional cost center access by restructuring the cost center tree rather than having their permissions directly modified, or a user who is granted a user type that carries broader permissions than their previous individual configuration. These indirect access changes are harder to log because they result from legitimate administrative actions that happen to have permission side effects, but they are the access changes most likely to be exploited intentionally or create unintended exposure accidentally.

Immutability, Retention, and Tamper Resistance

An audit log that can be modified by a PSA administrator is not an audit log — it is a record that someone chose not to modify. The distinction matters for compliance purposes because regulators and auditors evaluating financial controls want evidence that the log reflects what actually happened, not what the firm chose to record. Immutability — the property that log entries cannot be altered or deleted after they are written — is the technical characteristic that gives an audit log its evidentiary value.

• Retention period: financial audit trails need to be retained for the duration the firm’s regulatory and contractual obligations require. For publicly traded firms or government contractors, this may be seven years or more. Ask specifically how long the PSA retains audit log data, whether retention can be extended at the enterprise tier, and whether the log data can be exported for long-term archival in a separate system before it ages out of the PSA’s retention window.
• Tamper evidence: ask whether the audit log is stored in a way that would surface unauthorized modification — whether log entries are cryptographically signed, stored in an append-only data structure, or audited by a separate process that would detect deletions or alterations. Vendors that cannot answer this question specifically are likely storing audit logs in the same mutable database as operational data.
• Log access controls: who can read the audit log, and can those users modify it? The audit log should be readable by auditors and compliance staff and writable by no one — including PSA administrators. A log that administrators can modify provides no assurance to an external auditor.

Questions to Ask During Procurement

Three questions cut through vendor audit trail claims to the operational reality. Each should be answered with a live demonstration, not a feature description.

First: show us a time entry that was submitted, approved, invoiced, and then modified after invoice. What does the audit trail for that entry show, and can we export it? This tests whether financial record modification logging exists and whether it is accessible to finance and compliance teams without vendor involvement.

Second: show us the audit trail for a rate card change on an active engagement. What fields are logged, does the log preserve the prior rate, and how far back can we query? This tests billing configuration audit trail — the category most likely to be absent in platforms that treat configuration as system administration rather than financial record management.

Third: what is your audit log retention policy, is the log immutable, and how would we know if a log entry had been modified? This tests both retention and tamper resistance, and the quality of the answer reveals whether the vendor has engineered the audit log as a compliance control or bolted it on as a reporting feature.

Revenue recognition compliance for professional services firms is operationally complex in a way that most accounting software was not designed to handle. ASC 606 and IFRS 15 require firms to recognize revenue as performance obligations are satisfied — which means the timing of revenue recognition is tied to project delivery events, not to cash receipts or invoice dates. In a firm running dozens of simultaneous engagements across T&M, fixed-fee, milestone, retainer, and hybrid contract structures, manually tracking performance obligation completion and producing the correct recognized revenue entries each period is a significant accounting burden. Enterprise PSA software addresses this by embedding the revenue recognition logic directly into the delivery data model — connecting time entry, milestone completion, and contract structure to the GL entries the ERP needs to close the period correctly.

Why Revenue Recognition Is Operationally Complex for Services Firms

The complexity in services revenue recognition is not primarily a technical accounting problem — most CFOs and controllers understand the standards. It is a data problem. To recognize revenue correctly under ASC 606, finance needs to know, for every engagement and every period: what was promised to the client (the performance obligation), what has been delivered so far (satisfaction of that obligation), and what the standalone selling price of each deliverable was at contract inception. In a firm where projects run for months, scope changes, and the same client may have multiple overlapping engagements with different contract structures, assembling this information manually from time entries, project status reports, and contract documents takes significant effort and introduces significant risk of error.

Enterprise PSA software reduces that effort by maintaining the connection between the contract structure and the delivery data in a single system. The contract terms — which define the performance obligations — are configured in the PSA at engagement setup. The delivery data — time entries, expense records, milestone achievements, percent complete estimates — is captured in the PSA as the project runs. The PSA can therefore produce a recognized revenue calculation for each engagement each period that reflects both the obligation structure and the actual delivery progress, without requiring finance to reassemble that connection manually.

The Five-Step ASC 606 Model in a PSA Context

ASC 606 structures revenue recognition around five steps: identify the contract, identify the performance obligations, determine the transaction price, allocate the transaction price to the obligations, and recognize revenue as each obligation is satisfied. Enterprise PSA supports this model at the operational level — not as a theoretical framework but as a set of configurations that produce compliant revenue entries.

Step one and two — identifying the contract and its performance obligations — happen at engagement setup. The contract line items configured in the PSA correspond directly to performance obligations: a fixed-fee implementation phase is one obligation, a recurring support retainer is another, a T&M advisory arrangement is a third. Each is modeled separately, with its own transaction price and its own recognition method.

Steps three and four — determining and allocating the transaction price — require judgment that the PSA supports but does not make autonomously. When a contract contains both a fixed-fee implementation and a recurring support element, the standalone selling prices of each must be established and the bundled transaction price allocated between them. The PSA holds the resulting allocation as part of the contract structure. Finance documents the allocation methodology externally, and the PSA enforces it consistently across every revenue recognition period without requiring finance to re-perform the calculation.

Step five — recognizing revenue as obligations are satisfied — is where the PSA’s delivery data does the most work. For T&M obligations, satisfaction occurs as hours are delivered; revenue recognized equals hours times billing rate for the period. For fixed-fee obligations, satisfaction is measured by percent complete or milestone achievement, and the PSA applies the recognition method configured at setup to the delivery data it holds.

How Contract Type Determines the Recognition Method

The contract type configured for each engagement line item determines how the PSA produces its recognized revenue calculation. Enterprise PSA platforms support multiple recognition methods that correspond to the ASC 606 output method and input method approaches.

• T&M and not-to-exceed contracts: revenue recognized in the period equals approved time and expenses multiplied by the applicable billing rates. Recognition is contemporaneous with delivery — hours logged, approved, and within contract terms in the current period generate recognized revenue for that period. This is the simplest recognition method and the most directly tied to the PSA’s time entry data.
• Fixed-price, percent complete: recognized revenue each period equals the contract value multiplied by the percentage of the work completed as of period end. The PSA uses budget versus actuals data (hours consumed relative to total estimated hours, or costs incurred relative to total estimated costs) to calculate the percent complete figure. Finance reviews and confirms the percent complete estimate before the period-end GL entry is generated.
• Fixed-price, revenue schedule: recognized revenue follows a predetermined schedule — a fixed amount per period, or amounts tied to specific milestones regardless of delivery progress. The schedule is configured at contract inception and followed mechanically, with the PSA producing the correct recognized amount each period based on the schedule rather than actual delivery data.
• Service contracts with overages: a base amount of hours is contracted at a fixed price (recognized ratably over the service period), and hours above the contracted ceiling are billed at a T&M rate (recognized as delivered). The PSA models both the base contract and the overage tracking within the same engagement structure.

WIP Management and Period-End Compliance

Work in progress balance management is the operational mechanism that makes period-end revenue recognition tractable at scale. WIP represents work that has been delivered but not yet invoiced — or work that has been invoiced but not yet earned. Both create recognized revenue adjustments that need to flow through the GL at period end.

Enterprise PSA tracks WIP at the engagement level in real time: as time is approved and billing periods close, the PSA calculates the WIP balance for each engagement — the difference between what has been delivered, what has been invoiced, and what has been recognized. At period end, finance reviews the WIP positions across all active engagements, confirms the recognition calculations, and the PSA produces the GL journal entries — recognized revenue credits and WIP debit/credit adjustments — that the ERP needs to close the period. The alternative — finance manually calculating WIP for each of dozens of engagements from project status reports and contract documents — is the process that enterprise PSA replaces.

Example: A 240-person management consulting firm closes its Q3 books with 38 active engagements across T&M, fixed-fee, and retainer contract structures. For each engagement, the PSA calculates the recognized revenue for the quarter based on the contract type and delivery data: T&M hours approved, percent complete estimates for fixed-fee projects reviewed by project managers, and scheduled amounts for retainers. Finance reviews the recognized revenue report, adjusts three percent complete estimates where the project manager’s assessment differs from the input method calculation, and approves the period-end WIP entries. The PSA generates the GL journal entries for all 38 engagements and sends them to the ERP for posting. Total finance time for the revenue recognition close: four hours, down from the two days it required before the PSA was implemented.

Where the PSA Ends and the ERP Begins in the Recognition Chain

The division of responsibility between the PSA and the ERP in revenue recognition compliance is important to understand because it determines where the accounting controls sit. The PSA is not the system of record for recognized revenue — the ERP is. The PSA’s role is to produce recognition-ready data: the calculation of how much revenue should be recognized for each engagement each period, based on the contract structure and the delivery data it holds. The ERP’s role is to receive that data, apply any entity-level adjustments the accounting team requires, and post the recognized revenue to the appropriate GL accounts with the correct period date.

This division means that the revenue recognition compliance controls span both systems. The PSA controls the accuracy of the delivery data (time entry approval workflows, WIP balance calculations, percent complete estimates) and the contract structure (correct CLI configuration, standalone selling price allocation). The ERP controls the GL posting (correct account mapping, correct period, correct entity) and the financial statement output. Auditors reviewing revenue recognition compliance will examine both systems — the PSA’s contract and delivery records as evidence of performance obligation satisfaction, and the ERP’s GL entries as evidence of the accounting result.

Mixed-Contract Engagements and the Allocation Challenge

The most operationally demanding revenue recognition scenarios in professional services involve engagements where multiple contract types apply simultaneously — a fixed-fee implementation phase delivered concurrently with a T&M advisory arrangement for the same client under the same master agreement. Under ASC 606, these need to be identified as separate performance obligations with separately allocated transaction prices, even if they are invoiced together or managed as a single engagement from the client relationship perspective.

Enterprise PSA handles this through the contract line item model: each obligation within an engagement is configured as a separate CLI with its own contract type and recognition method. The fixed-fee phase generates recognition based on percent complete. The T&M phase generates recognition based on approved hours. The two streams are calculated independently and aggregated at the engagement level for reporting purposes, while remaining separately auditable at the CLI level. Finance can produce a recognized revenue breakdown by obligation for any engagement — which is the evidence structure that auditors request when reviewing multi-element arrangement accounting under ASC 606.

Questions to Ask During PSA Evaluation

Three questions differentiate PSA platforms with genuine ASC 606 support from those where recognition is a reporting feature rather than an operational one.

First: show us how the platform handles a fixed-fee engagement where the percent complete estimate is revised mid-project due to scope change. Specifically, what happens to the cumulative recognized revenue when the estimate changes, and how does the catch-up adjustment appear in the period-end GL entry? This tests whether the platform applies the ASC 606 cumulative catch-up method correctly or simply recognizes the current period’s incremental amount without adjusting for prior period over- or under-recognition.

Second: show us a multi-element engagement with a fixed-fee phase and a T&M retainer configured as separate CLIs. Produce the period-end recognized revenue for both obligations from the same engagement record. This tests whether the CLI-level multi-method recognition model actually works in a production scenario or whether it requires manual separation at the end of each period.

Third: how does the platform handle a change to the contract terms after project start — for example, a modification that adds a new deliverable and adjusts the transaction price? Does the platform support the modification accounting approaches in ASC 606 (separate contract, cumulative catch-up, or prospective treatment) or does it require the accounting team to handle all modifications manually outside the system? The answer reveals the depth of the ASC 606 implementation — modifications are where most PSA platforms’ compliance support runs out.

Professional services firms operating in regulated industries face PSA security and governance requirements that go beyond the standard enterprise procurement checklist. The specific requirements vary significantly by sector — government contractors face ITAR and DFARS compliance obligations that financial services firms do not, and publicly traded firms face SOX internal control requirements that healthcare-adjacent consultancies may not. What all of them share is that the PSA is not treated as a generic business application during regulatory review. It is treated as a system that holds financial records, billable hour data, and potentially sensitive client project information — which means it falls within the scope of controls that auditors, regulators, and contracting authorities will examine. This article maps the governance requirements by regulated industry type and identifies the PSA capabilities that either satisfy or create risk for each.

The Security Baseline That Applies Across All Regulated Industries

Before addressing industry-specific requirements, four security controls are table stakes for any PSA deployment in a regulated environment. These are the controls that every regulatory framework asks about, in some form, for any system that holds financial or client data.

Access control with audit trail: the PSA must enforce role-based access that prevents unauthorized users from viewing or modifying financial records, and every access change — user creation, permission modification, deprovisioning — must be logged with timestamp and actor identity. Identity federation via SAML 2.0 or equivalent, connected to the firm’s existing identity provider, ensures that the PSA’s access model is governed by the same controls as the rest of the firm’s IT infrastructure. A PSA that maintains its own credential store, independent of the firm’s identity provider, creates a governance gap that regulators in every sector will identify.

Encryption in transit and at rest: all data transmitted to and from the PSA must be encrypted using current standards (TLS 1.2 or higher), and data stored in the PSA’s infrastructure must be encrypted at rest. For regulated industries, the encryption key management question matters — vendor-managed keys are acceptable in most frameworks, but some regulated environments require customer-managed keys or hardware security module (HSM)-based key management.

SOC 2 Type II certification: as covered in the dedicated article, a current SOC 2 Type II report with a well-defined audit boundary covering the production environment is the minimum compliance evidence most regulated procurement processes require. The audit period must be current — a report with an observation period ending more than twelve months ago is typically insufficient for active procurement reviews in regulated sectors.

Data residency: regulated environments often impose geographic constraints on where data can be stored and processed. Understanding the PSA vendor’s infrastructure geography — primary data centers, backup locations, disaster recovery replication — and verifying it against the firm’s regulatory requirements is a procurement step that is often skipped and then discovered as a problem post-contract.

Government Contractors: ITAR, DFARS, and Controlled Data

Professional services firms that contract with the US federal government — particularly in defense, aerospace, and national security — face controls under the International Traffic in Arms Regulations (ITAR) and the Defense Federal Acquisition Regulation Supplement (DFARS). These controls govern where data about US persons and controlled technical information can be stored and who can access it.

For PSA software, the relevant ITAR and DFARS question is whether the PSA vendor’s infrastructure is operated by US persons on US soil, whether the vendor’s cloud infrastructure is hosted on a FedRAMP-authorized platform, and whether the vendor has a data processing agreement that commits to the geographic and access restrictions that ITAR and DFARS require. Most commercial PSA vendors have not sought FedRAMP authorization — the cost and complexity of authorization is significant — which means government contractors often face a choice between a FedRAMP-authorized platform with less PSA functionality and a commercial PSA platform that requires additional contractual controls to manage the regulatory gap.

The practical resolution for many government-adjacent professional services firms is to scope carefully what data enters the PSA. Time entries, billing records, and project financial data are typically non-controlled information that does not carry ITAR classification. The firm’s obligation is to ensure that no controlled technical data — project specifications, technical drawings, classified information — enters the PSA system. Governance controls around what users are permitted to enter in project notes, task descriptions, and expense narratives become the primary compliance mechanism when the PSA platform itself is not FedRAMP-authorized.

Financial Services Firms

Management consulting, IT services, and advisory firms that serve financial services clients — banks, insurance companies, asset managers — often inherit their clients’ regulatory scrutiny through vendor risk management programs. A PSA holding billable data from a bank engagement may be subject to that bank’s vendor risk assessment, which can include requirements drawn from the bank’s own regulatory framework — OCC guidance, FFIEC standards, or state banking regulations depending on the client.

Example: A 260-person management consulting firm specializing in financial services regulatory projects wins a multi-year engagement with a large regional bank. The bank’s vendor risk management team requires the consulting firm to complete a 75-question security assessment covering data handling, access controls, encryption, incident response, and subprocessor management for all software systems that will process data related to the engagement. The PSA is listed as an in-scope system because it will hold billable hours, project records, and engagement financial data related to the bank client. The consulting firm’s ability to pass this assessment determines whether the engagement can proceed under the agreed commercial terms.

The PSA governance requirements that typically arise in financial services vendor assessments include: data isolation (can client-specific project data be restricted to users working on that engagement?), subprocessor disclosure (the full chain of infrastructure providers who handle client data), incident notification (what is the vendor’s contractual obligation to notify the customer of a security incident, and within what timeframe?), and penetration testing evidence (current external penetration test results covering the systems that will process the client’s data).

Healthcare-Adjacent Consulting and HIPAA Considerations

Professional services firms advising healthcare organizations — hospitals, health systems, health insurance companies — may encounter HIPAA obligations if their project work involves access to protected health information (PHI). A PSA is unlikely to hold PHI directly in most consulting engagements, but the governance question is whether the PSA is considered part of the firm’s HIPAA compliance boundary.

The practical answer for most healthcare-adjacent consulting firms is that the PSA sits outside the PHI boundary — project financial records, billable hours, and engagement notes do not constitute PHI even when the engagement client is a covered entity. The obligation falls on the firm to ensure that PHI does not enter the PSA through inappropriate use (consultants noting PHI in time entry comments or project notes, for example). Administrative controls — clear policies about what data can be entered in the PSA — are typically the governance mechanism, supplemented by a Business Associate Agreement (BAA) if the PSA vendor will be handling any data that could reasonably constitute PHI.

Publicly Traded Firms and SOX Internal Controls

For professional services firms that are publicly traded, or subsidiaries of publicly traded parents, the PSA falls within the scope of Sarbanes-Oxley (SOX) Section 404 internal controls over financial reporting. SOX requires management to assess and certify the effectiveness of internal controls that could materially affect the financial statements — which includes the systems that generate, process, and report revenue and billing data.

The SOX governance requirements that apply to PSA software are specific and well-understood. Change management controls govern how the PSA is updated — changes to billing configurations, rate cards, and financial rules must follow an approval and testing process documented in the IT change management log. Access controls govern who can modify financial data in the PSA, with segregation of duties enforced so that the person who creates an invoice cannot be the same person who approves it. Financial reporting controls govern how data flows from the PSA to the GL, with documented reconciliation procedures and evidence that the reconciliation was performed each period. The audit trail capabilities discussed in the dedicated audit trail article are the evidentiary foundation for SOX control testing — external auditors will request them as part of their annual Section 404 review.

Client Contract Audit Rights

Beyond regulatory frameworks, many professional services engagements include contractual audit rights that give the client the ability to audit the firm’s time records, billing data, and financial records related to the engagement. T&M contracts in particular frequently contain provisions allowing the client to request documentation supporting any invoice — the underlying time entries, the rates applied, the billing rule structure that produced the invoice total.

• Time entry traceability: every invoice line must be traceable back to individual time entries with timestamps, consultant identity, project, task type, and rate. The PSA must support this export in a format that the client’s auditors can review without special software or PSA access.
• Rate card documentation: the billing rates applied to each engagement must be documentable as of the invoice date — not just the current rate card state. A PSA with rate card version history satisfies this; one without it requires supplementary documentation managed outside the system.
• Scope change trail: when the engagement scope changes and a change order adjusts the contract terms, the PSA record of both the original contract and the amendment must be preserved and producible. Clients auditing a T&M engagement will ask for the contract at each amendment stage.

How to Structure the Regulatory Evaluation

The most effective approach to PSA security and governance evaluation in a regulated environment is to separate the assessment into three distinct workstreams rather than treating it as a single procurement checklist.

The first workstream is vendor security assessment: SOC 2 Type II report review, penetration test summary, subprocessor disclosure, data residency confirmation, and encryption specification. This workstream is conducted by the firm’s IT security team or an external assessor, and the outputs are binary — either the vendor meets the requirement or they do not.

The second workstream is platform governance capability assessment: does the PSA’s access control model, audit trail capability, accounting period governance, and integration security architecture support the controls the firm needs to implement? This is a functional evaluation conducted against the specific regulatory and contractual requirements the firm faces — not a generic security checklist. A government contractor evaluating DFARS compliance needs different answers than a publicly traded firm evaluating SOX readiness.

The third workstream is contractual and legal review: does the vendor’s data processing agreement, BAA (if applicable), subprocessor agreement, and incident notification clause meet the firm’s contractual obligations to its regulators and clients? This workstream is conducted by the firm’s legal team and often takes longer than the technical assessments — beginning it in parallel with the functional evaluation, rather than sequentially, prevents it from becoming the procurement bottleneck.