An Evaluation Checklist for Analytical Buyers Who Won’t Accept “We Take Security Seriously”
Audience: HR Directors, CFOs, and IT Heads evaluating or renewing a payroll software contract | Read time: 9 min
Your payroll system holds more sensitive personal and financial data than almost any other application in your organisation. Every employee’s PAN, UAN, Aadhaar linkage, bank account, salary history, tax records, and in many cases investment declarations — all in one platform, accessible via the internet.
Most payroll SaaS vendors respond to security questions with the phrase “we take security seriously.” This article gives you the questions to ask and the answers to demand — specific, verifiable, contractual. Anything short of that is a marketing claim, not a security standard.
1. Certification: The Baseline You Must Verify
Certifications are not guarantees, but they are the minimum threshold of evidence that a structured security program exists. Without a valid current certification, a vendor’s security claims are unaudited assertions.
| Certification | What it means | How to verify |
| ISO 27001:2022 | Information Security Management System is audited annually by an accredited third party. The 2022 version includes specific controls for cloud environments, threat intelligence, and ICT supply chain security. | Ask for the certificate PDF — it shows issuing body, certification scope, and expiry date. Verify the issuing body is NABCB-accredited or IAF MLA-signatory. Paybooks holds ISO 27001:2022 certification. |
| SOC 2 Type II | Six-month operational audit of security, availability, processing integrity, confidentiality, and privacy controls. Type II (operational period) is more valuable than Type I (point-in-time). | Ask for the SOC 2 Type II report summary. The full report is typically under NDA. Verify the audit period (should be within the last 12 months) and auditor name. |
| VAPT (Vulnerability Assessment and Penetration Testing) | Not a certification — a periodic test by an independent security firm that identifies vulnerabilities in the application and infrastructure. Should be conducted at least annually. | Ask: “When was your last VAPT conducted, by which firm, and can you share the remediation summary?” A vendor unwilling to share even a summary has something to hide. |
Always ask for the actual certificate, not just a verbal confirmation. ISO 27001 certificates have an expiry date. A certificate that expired 18 months ago means the organisation was certified — not that it currently is. The current date matters.
2. Data Architecture: How Your Data Is Isolated
A payroll SaaS platform serves many clients simultaneously. The critical question is how your data is separated from other clients’ data — and what prevents a breach in one client environment from exposing another.
Questions to ask — and what acceptable answers look like
| Question | What an acceptable answer looks like |
| How is client data logically separated in your database architecture? | Each client’s payroll data is isolated at the database level using tenant-specific schemas or separate database instances — not just application-level filters. A query to your database cannot return another client’s records. |
| Where is data physically stored? Is it in India? | Primary data stored in India-based data centres (AWS Mumbai, Azure India Central, or equivalent). If backup data is stored offshore, the vendor should disclose the location and applicable data protection framework. |
| What encryption is applied to stored payroll data? | AES-256 encryption at rest is the current standard. Encryption should be applied at the database level, not just at the storage volume level. Keys should be managed separately from the data they protect. |
| What encryption is used for data in transit? | TLS 1.2 or higher for all data in transit between browser/mobile app and server. HTTPS-only, with HSTS enforced. Older SSL/TLS protocols (TLS 1.0, 1.1) should be disabled. |
| Who at the vendor has access to our payroll data? | Access limited to named individuals on a need-to-know basis. All access is logged. Production data access by vendor staff should be through a privileged access management system — not via direct database credentials. |
| Are Aadhaar numbers stored in your system? | Aadhaar storage is governed by the Aadhaar Act and UIDAI regulations. Compliant vendors either do not store raw Aadhaar numbers or store only the last four digits for display purposes. Full Aadhaar storage without UIDAI authorisation is a regulatory violation. |
3. Access Controls: Who Can See and Do What
A payroll data breach is often not an external attack. It is an internal user with excessive privileges — a departing employee with access not revoked, or an administrator who can export the entire salary file without audit trail.
| Access control requirement | What to verify |
| Role-based access control (RBAC) | Can you configure different permission levels — Payroll Admin, HR Manager, Employee, Finance Viewer — with different access to salary data, reports, and configurations? An employee should not see a colleague’s salary. A Finance Viewer should not be able to run payroll. |
| Multi-factor authentication (MFA) | MFA should be available and enforceable for all admin users — not just optional. Ask whether you can make MFA mandatory for your organisation’s admin accounts. OTP via email alone is insufficient; TOTP app or SMS is the minimum. |
| Single Sign-On (SSO) support | If your organisation uses Google Workspace, Microsoft Entra, or Okta, the payroll platform should support SSO — so that when an employee is deprovisioned in your identity provider, their payroll access is also revoked immediately. |
| Audit trail: every action logged | Every login, every payroll run, every salary change, every export, every configuration change should be logged with timestamp, user, and IP address — and the log should be immutable (cannot be edited or deleted by any user). Ask: “Can I see who exported the full salary file last month?” |
| Data export controls | Can you restrict which user roles are allowed to bulk-export employee data? Can you require approval for bulk exports? An uncontrolled export capability means a single disgruntled employee can download the entire payroll database and walk out. |
| Session management | Automatic session timeout after inactivity (15–30 minutes for admin roles). Concurrent session restriction — should not allow the same account to be logged in from multiple locations simultaneously without alerting. |
4. Availability and Disaster Recovery
Payroll has a hard deadline every month. A system outage on salary day is not an IT inconvenience — it is an employment law problem. The Payment of Wages Act requires salary to be paid on the contracted date.
| Requirement | What to demand in your contract |
| Uptime SLA | 99.9% annual uptime is the industry standard (equates to under 9 hours downtime per year). Demand this specifically for the payroll processing window — the 48–72 hours around month-end when payroll is being approved and bank files are generated. General SLAs that exclude “scheduled maintenance” are meaningless for a hard-deadline process. |
| Recovery Point Objective (RPO) | RPO = maximum acceptable data loss in a disaster. For payroll, this should be 1 hour or less — meaning daily automated backups at minimum, ideally real-time or near-real-time replication. An RPO of 24 hours means you could lose an entire day of payroll changes in a failure. |
| Recovery Time Objective (RTO) | RTO = time to restore service after a failure. For payroll, demand RTO under 4 hours for any failure that occurs during the payroll processing window. An RTO of 24–48 hours is commercially stated but unacceptable for salary day operations. |
| Backup verification | Backups that are never tested are not backups — they are unverified copies. Ask: “How often do you test backup restoration? When was the last restore drill conducted?” A credible answer includes a specific date and frequency. |
| Data portability on exit | You must be able to export your complete payroll data in a machine-readable format (CSV/Excel) at any time — not just at contract end. Your data is yours. A vendor who restricts export capability is creating lock-in through data hostage-holding. |
5. Incident Response: What Happens If There Is a Breach
India’s Digital Personal Data Protection Act, 2023 (DPDP Act) requires data fiduciaries to notify breaches to the Data Protection Board and affected individuals. Your payroll vendor processes personal data on your behalf as a data processor. Their breach is your breach.
- Demand a written incident response commitment: the vendor must notify you within 24 hours of discovering any breach involving your data — not after internal investigation is complete.
- Ask for the vendor’s breach notification SLA: time from discovery to client notification, and time from client notification to regulatory notification support.
- Verify the vendor has a documented incident response plan — ask to see the outline. A plan that exists on paper is not sufficient; ask when it was last tested and what the test scenario was.
- Confirm indemnification terms: if a breach caused by vendor negligence results in regulatory penalties or damages, what is the vendor’s liability cap and indemnification scope? A liability cap equal to one month’s contract value for a breach exposing 500 employees’ financial data is commercially unreasonable.
- Check for cyber insurance: ask whether the vendor carries cyber liability insurance, the coverage amount, and whether it covers third-party claims (your employees or regulatory penalties arising from a breach).
Under the DPDP Act, you are the data fiduciary for your employees’ personal data. Your payroll vendor is a data processor. The legal obligation to notify affected individuals and the Data Protection Board rests with you — regardless of whose systems caused the breach. Vendor negligence does not reduce your obligation.
Vendor Security Evaluation: The Summary Checklist
Use this to score a vendor before contract signature. Ask for each item in writing or via a formal security questionnaire. Score: 2 = verified and documented; 1 = claimed but not verified; 0 = absent or refused.
| Item | Claimed | Verified | Your score |
| ISO 27001:2022 certificate — current, with certificate PDF | □ | □ | |
| VAPT conducted within last 12 months by named third-party firm | □ | □ | |
| Tenant-level data isolation at database layer confirmed | □ | □ | |
| AES-256 encryption at rest; TLS 1.2+ in transit | □ | □ | |
| Primary data stored in Indian data centres | □ | □ | |
| RBAC with configurable role and permission levels | □ | □ | |
| MFA enforceable for all admin users | □ | □ | |
| Immutable audit trail for all actions, exportable | □ | □ | |
| 99.9% uptime SLA in contract with payroll window carve-out | □ | □ | |
| RPO ≤ 1 hour, RTO ≤ 4 hours for payroll window | □ | □ | |
| Data portability: full export in CSV/Excel at any time | □ | □ | |
| Breach notification SLA: ≤24 hours from discovery to client notification | □ | □ | |
| DPDP Act compliance documentation available | □ | □ | |
| TOTAL score (max 26 verified) | /26 |
Interpretation: 22–26 verified = strong security posture; proceed with normal due diligence. 16–21 verified = acceptable with specific gaps to address contractually. Under 16 verified = significant gaps; reconsider or require remediation commitments in writing before signing. Any refusal to answer = treat as 0.
| Paybooks holds ISO 27001:2022 certification. Data stored in Indian data centres. We welcome security questionnaires. Send us your checklist — we will respond with documentation, not assertions. paybooks.in | info@paybooks.in | +91 80 4710 7171 |
