A step-by-step guide on how to assess a workplace SaaS

Step 1: Classify the data before you assess the vendor

You cannot judge whether controls are adequate without knowing what they protect. Document what data will be collected and used. 

Personal data collected: names, employee IDs, contact details, vehicle registrations, dietary preferences, accessibility requirements

Behavioural data generated:  attendance patterns, location within buildings, timing

Special-category data: accessibility and dietary information can reveal health or religion, which raises the bar under GDPR Article 9 and DPDP

Integration reach: what the platform can read from HRMS and what it can write to access control

Step 2: Certifications

Some major certifications that the workplace SaaS you are evaluating must possess:

• ISO/IEC 27001
• ISO/IEC 27701
• SOC 2 Type II
• CSA STAR

Three things to check on every certificate:

• Read the scope statement, not the badge. A certificate covering the corporate office but not the production environment is close to worthless.
• Check the expiry date and the certification body.
• Ask for the full SOC 2 Type II report under NDA, not the summary. Then read the exceptions section. Vendors with clean reports share them readily; hesitation is itself a finding.

Step 3: The technical questionnaire

Keep it to what you’ll actually verify.

• Encryption

• • • Key management: who holds keys, and can they access your data?

• Access control

• • • Role-based access with least privilege
    • MFA enforced for admin accounts, including vendor-side support staff
    • Periodic access reviews, with evidence

• Architecture

• • • Single tenant or multi-tenant? If multi-tenant, how is isolation enforced?
    • Where is data hosted, and can you specify the region?

• Development and testing

• • • Testing frequency, by whom, and will they share the summary?
    • Vulnerability management SLAs by severity

• Logging and response

• • Centralised audit logging, and whether you can access your own logs
  • Documented incident response, with notification timelines
  • Backup and disaster recovery

Step 4: Privacy and contractual position

Contract must include:

• A Data Processing Agreement specifying processing purposes and instructions
• Standard Contractual Clauses or equivalent if data crosses borders
• Documented DSAR support process
• Breach notification timelines, ideally 24–72 hours
• Retention and deletion terms, including what happens at contract exit
• Explicit confirmation your data isn’t used to train models for unrelated purposes

Ask about DPIAs. Whether the vendor has conducted a Data Protection Impact Assessment, and whether they’ll support yours. Location-tracking within buildings frequently triggers a DPIA requirement.

Step 5: AI-specific questions

Increasingly relevant, and rarely covered in standard questionnaires.

• What AI features exist, and what data do they use?
• Is customer data used to train models? If so, is it your data, and can you opt out?
• Are third-party LLM providers involved, and what’s the data-sharing arrangement?
• Does any AI make automated decisions with significant effects on employees? 
• Can administrators review and override AI recommendations?

The reassuring answer for workplace platforms is that AI optimises space and scheduling rather than profiling individuals, but get it confirmed rather than assumed.

Step 6: Verify, don’t accept

Everything above is what a vendor tells you. Verification is separate:

• Read the SOC 2 exceptions. Not the cover letter.
• Reference-check a client of your size. Ask them specifically about incident handling and support responsiveness, not features.
• Test the integrations in a pilot. SSO, HRMS sync and access control are where real-world security gaps appear, and they never appear in a demo tenant.
• Check the DPA against your legal template before signing, not after.

Red flags to avoid at all cost

• Certificates whose scope excludes the production environment
• Refusal to share a SOC 2 Type II report under NDA
• Vague answers on whether customer data trains models
• No documented breach notification timeline
• A DPA that has to be “checked with legal” rather than produced
• Security answers coming from sales rather than a security or compliance function