)
)
PSA security and compliance: Summary & key takeaways
What the badge means: A "SOC 2 compliant" badge is marketing shorthand, and the evidence behind it is a CPA firm's dated attestation report.
What to read first: Read the audit dates, scope, exceptions and the customer duties the report hands back to you.
Where margin leaks: Your own PSA permissions decide who can see, or work out, your bill rates, cost rates and margin.
What to request: Ask for the SOC 2 report, bridge letter, ISO certificate, DPA, sub-processor list and AI data terms before you sign.
PSA security and compliance means checking two things: that a vendor's controls are independently proven, and that your permissions keep margin data with the right people. PSA here means a professional services automation platform, which connects projects, resources and financials, not the IoT security scheme that shares the acronym.
At Teamwork.com I brief agencies and research partners from the client side, and I'll take one dated, readable report over a wall of badges. Five checks cover the vendor's evidence, and a visibility test covers your own rates and margin, because the vendor's report stops where your permissions begin.
Why your PSA is a finance system, not just an IT one
Your PSA is a finance system because it keeps bill rates, cost rates, budgets, profitability and invoices in one place, next to client project notes. A cost rate is what an hour of someone's time costs the firm, which puts it close to that person's pay. If anyone on your team is new to the category, start with what PSA software is and how it works.
Your clients have a stake in that data too. Their vendor-risk questionnaires and contract audit rights reach any system holding their project and billing records, and your PSA is one of them. They have good reason to ask, since Verizon's 2025 Data Breach Investigations Report found third-party involvement in 30% of breaches, double the year before. For you, that means a vague answer about your PSA's security reads to a client as a vague answer about your firm.
"SOC 2 compliant" is not something an auditor signs
A finance system needs finance-grade evidence, and SOC 2 is a CPA firm's report on a vendor's controls rather than a compliance certificate. The Journal of Accountancy's February 2026 article on SOC credibility, published by the AICPA, calls compliance "a term never used in SOC 2 examinations". The same article warns that fast, easy reports threaten SOC credibility, and tells buyers to vet the CPA firm behind the attestation.
The report type matters as much as the auditor. A Type 1 report checks whether controls were designed properly at one point in time. A Type 2 report checks design and operation across a period, commonly six to twelve months.
SOC 1 is easy to overlook, yet it's the report closest to a finance team's job. The AICPA describes SOC 1 as an examination of controls likely to be relevant to your internal control over financial reporting. If your invoices or revenue recognition rely on PSA data your auditors test, ask for SOC 1 as well.
ISO/IEC 27001 certifies that the vendor runs and maintains an information security management system. It tells you a managed system exists, while SOC 2 Type 2 tells you specific controls worked over a period.
Put together, that gives a working rule: for a PSA holding billing data, ask for SOC 2 Type 2 at minimum. Add SOC 1 when invoices depend on PSA data, and treat ISO/IEC 27001 as a strong complement to SOC 2.
SOC 2 Type 2 vs SOC 1 vs ISO/IEC 27001: what each proves to a finance team. Each answers a different finance question, so one badge rarely covers a full review.
Evidence type
The five-check PSA security review
Knowing which report to request is the easy half, because most of its value sits in five places finance teams tend to skip. Add these checks to your PSA features and requirements list next to time, resourcing and billing. Commercial questions such as pricing and pilots belong in your software buyer's guide, so this review sticks to PSA security and compliance evidence.
1. Check the dates before the opinion
Start with the audit period: the start date, the end date and how long the Type 2 window ran. If the period ended more than 12 months ago, ask why and when the next report lands. If more than three months have passed since it ended, ask for a bridge letter.
A bridge letter is management's own statement that nothing material has changed since the period closed. No auditor tests it, so it buys you time and nothing more. Only then read the opinion: unqualified is clean, while qualified means the auditor found problems serious enough to flag.
2. Find what sits outside the audit boundary
The system description tells you which product, environment and locations the auditor actually tested. Under the carve-out method, a subservice organization such as the cloud host is excluded. Ask for the host's own report, and if the product you're buying isn't in the system description, the report doesn't cover it.
3. Turn the customer duties into your own checklist
Complementary user entity controls, or CUECs, are the controls the vendor assumes you run yourself. They usually include reviewing user access, removing leavers, protecting credentials and setting permissions. The vendor's assurance stops at that list, and your own permissions take over.
Next, read the exceptions section, where the auditor lists controls that failed testing alongside management's response. An exception in access control or change management, on a system holding your rates, deserves a direct question.
Then hand the CUEC list to whoever runs your PSA admin, with an owner and a review date against each line. Without a name beside it, every duty on the list belongs to nobody.
4. Read the data terms, not just the security terms
A data processing agreement (DPA) sets what a vendor may do with your data and who else may touch it. GDPR Article 28 requires your written authorization before a processor adds sub-processors, and lets you object to changes. Article 33 gives you, as controller, 72 hours after becoming aware of a breach to notify the regulator.
The vendor's breach notice to you has to fit well inside that window. Check it alongside the objection window, hosting regions and what happens to your data at exit. Integrations move data too, so list every connected tool that receives rates or invoice data as part of mapping your PSA software integrations.
5. Ask how AI features touch your data
AI raises new questions: is your data used to train models, which AI sub-processors see it, and where does processing happen? Ask too whether the AI acts only within each user's permissions, and whether a person approves anything it writes back. The AI I've built into my reporting, status updates and project admin at Teamwork.com passes through a person first; ask vendors where that checkpoint sits.
PSA vendor evidence request list
Every check above maps to a document you can request in a single email. The list works on the PSA you already run as well as the ones on your shortlist.
Evidence to request
Send the list before the final demo rather than after signature. Vendors answer faster while the deal is still open, and any gap you find can still shape the contract.
Who can see your rates? Run a finance data visibility test
Of the customer duties in check 3, permissions carry the most money: give each role the rate data its job needs, and nothing more. That includes anything a role can calculate from the screens it already sees.
Take an illustrative project where one person has logged eight hours and the budget's reported cost is $800. Anyone with access to that profitability view can work out a $100 an hour cost rate, close to that person's pay. Nobody breached anything or exported a file; the arithmetic did the leaking.
Nobody sets out to over-share pay data. Permissions drift because people are busy delivering, and access granted in a hurry rarely gets a second look. If you're rolling out a new system, the PSA implementation guide covers keeping rate tables locked down from the start.
Finance data visibility matrix. Most roles need far less money data than finance does, so treat this as a starting point for your own policy.
Role
A matrix only holds if it matches how people actually work. Three rules keep it honest:
If a role doesn't price work or approve invoices, hide cost rates from it.
If only one or two people log time on a project, treat profitability access there as cost-rate access.
If someone changes role or leaves, review their access that week, plus a quarterly review for everyone.
On the agency side, client-facing teams changed often around me, and a handover only held up when someone had written things down. Access deserves the same discipline, because old permissions travel with a mover unless the handover notes say otherwise.
Permissions decide who sees a rate today, but billing disputes and client audits turn on proving which rate applied when. Ask whether the PSA keeps a dated rate history and time-entry history, and who can edit them; a record anyone can rewrite settles nothing.
Where this review stops working
The five checks and the visibility test cover most PSA decisions, but a clean report only describes a past period. Anything the vendor released since then isn't in it, so ask what changed after the period closed.
Team size is the second limit, though firms without a security lead can still run most of the method. Finance can handle checks 1 and 3 and the visibility test. Checks 2 and 4 can go to your IT provider or outsourced security partner.
The third limit is the data itself, because some of it shouldn't enter a PSA at all. Health records, card data and other regulated client data usually belong elsewhere, so set a policy for what goes into time-entry descriptions and notes.
The last is reuse: when a client sends its own questionnaire, answer it from your evidence pack, not the vendor's marketing page. Your PSA security and compliance answers then rest on documents you've read yourself.
How Teamwork.com keeps rates, time and AI inside the right permissions
Teamwork.com is the agentic PSA (professional services automation platform) that connects projects, resources and financials, and it turns the visibility test into a setting. It holds a SOC 2 Type 2 report and ISO/IEC 27001:2022 certification. Your finance system stays the system of record.
Give each role only the money data its job needs: a budget view shouldn't double as a cost-rate lookup. View Hourly Rates, View Project Budget and View Project Budget Profitability are separate project permissions, and site-wide rates stay with site owners and owner-company admins. Client users never see project profitability, and collaborators can't hold rate or budget permissions, so your visibility matrix lives in the product.
)
Prove which rate applied when: a billing dispute goes badly when nobody can show the rate in force on the day. Time tracking runs through timesheet approvals, and project rate history records each value, the date it took effect, and who changed it when. Rate changes never alter time on completed invoices, so you answer a queried bill with a dated record.
)
Let AI work inside the same permissions as your people: an assistant shouldn't read rates its user can't see. The Teamwork.com MCP server connects tools such as Claude or ChatGPT over OAuth, and acts only on what the connected account can. Customer data isn't used to train AI models, and Ask AI skills ask you to confirm before saving, so a person approves each change.
)
OIC Advisors moved budget reporting, portfolio dashboards and time tracking out of PowerPoint, Excel and Microsoft Project into Teamwork.com. The firm reports 100% transparency in billing hours and budgets, and 100% less time spent manually generating reports. Every report nobody exports is one less spreadsheet of rate data outside your permissions.
)
Four more controls answer the rest of the review, and the sub-processor terms sit in the Teamwork.com data processing agreement.
The job
The badge gets a vendor onto your shortlist; the evidence and the permissions decide whether your margin data stays yours.
)
)
)
)