How to evaluate the security of workplace safety and compliance software

The short answer

Evaluating the security of safety software comes down to four questions: where your data lives, who can reach it, what happens when something goes wrong, and what independent proof exists for the answers. A certificate such as ISO/IEC 27001 answers only the fourth, and only partly. The rest you establish by asking specific questions and insisting on written answers you can check.

Everything below is built for a reader who is not a security specialist but has to sign off on a vendor. It does not name or rank any product. By the end you should be able to take any vendor's security page, work out what it does and does not say, and send a short list of questions that separates a vendor who has done the work from one who has written the page.

What you are actually deciding

You are deciding whether to hand a third party information you remain legally responsible for. That responsibility does not transfer with the data. In New Zealand, the Office of the Privacy Commissioner's guidance on third-party providers is explicit: where a provider stores or processes information solely on your behalf, section 11 of the Privacy Act 2020 treats the provider as you, and "your organisation remains fully responsible under the Privacy Act for what happens to that information". Australia's Privacy Act 1988 reaches a similar place by a different route.

That reframes the exercise. You are not asking "is this vendor secure" — a question nobody can answer with a yes — but "can I show that I took reasonable care in choosing and contracting with this vendor, and will I find out in time if something goes wrong". Four questions cover it:

1. 1.Where does the data live? The hosting provider, the region, whether backups leave that region, and which other companies handle any part of it.
2. 2.Who can reach it? Your own users, controlled by roles you configure; and the vendor's staff, controlled by their internal access rules.
3. 3.What happens when something goes wrong? Backups and recovery for the ordinary failures; incident response and notification for the serious ones.
4. 4.What proof exists? Certifications, independent testing, and written answers — as distinct from a page of adjectives.

Notice that none of these is answered by the phrase "we take security seriously". A vendor's security page is useful exactly in proportion to how many of the four it answers with specifics you could check.

What a certification proves, and what it doesn't

An ISO/IEC 27001 certificate proves that an accredited certification body audited the vendor's information security management system against the standard, within a stated scope, and found it conformed on the dates of the audit. It does not prove the product is free of vulnerabilities, it does not cover anything outside the scope statement, and it says nothing about whether the specific control you care about is configured the way you need. Treat it as evidence about process and governance, not as a promise about outcomes.

Two points from ISO itself are worth having in mind. First, ISO does not certify anyone: "certification is performed by external certification bodies, thus a company or organization cannot be certified by ISO". Second, accreditation — "the formal recognition by an independent body, generally known as an accreditation body, that a certification body operates according to international standards" — is what gives a certificate its weight. An unaccredited certificate is a private opinion. An accredited one is backed by a chain you can follow: the certification body is checked by a national accreditation body, and the certificate is listed on a public register.

The reason certification matters more than a self-declared list of controls is the cycle behind it. Under ISO/IEC 17021-1, the standard that governs certification bodies, a certificate runs on a three-year cycle with surveillance audits at least once each calendar year in between. So a valid accredited certificate means an outsider looked recently and is scheduled to look again — which is the opposite of a security page that was written once.

How to read a certificate

Read the scope statement first, then the dates, then verify it on the accreditation register — in that order, because most buyers do the opposite and stop at the logo. The scope is the sentence describing what the certificate covers, and a certificate can be entirely genuine while covering less than you assumed: a head-office function, a particular product line, or a data centre the product does not run in.

Other attestations exist and the same reading applies. A SOC 2 report, common with US-based vendors, is an auditor's report rather than a certificate, and it is only meaningful if you read which trust criteria were in scope and over what period. Whatever the document, the questions are the same: what exactly was examined, by whom, when, and how do I check.

Data residency is a question about jurisdiction, not latency

Ask which country and which cloud region the production database, file attachments and backups live in, and get it in writing. The answer determines whose law applies to the data at rest, whose courts can compel access to it, and whether your own procurement policy is satisfied. It is not primarily a performance question, and a vendor who answers it with "the cloud" or names only the provider without the region has not answered it.

For New Zealand organisations, the Privacy Act 2020 position is more subtle than "offshore is bad". Where a provider only stores and processes on your behalf, the Privacy Commissioner's guidance is that you are not "disclosing" to it at all — section 11 makes the provider you for the Act's purposes — so information privacy principle 12, which governs disclosure outside New Zealand, may not even be engaged. What is always engaged is your own duty to keep the information safe, wherever it sits, and the guidance is direct about the consequence: "you should make sure that you have a robust agreement in place with them that requires them to keep the information safe and gives you a remedy when things go wrong". Where IPP 12 does apply, the test is whether the recipient is subject to "comparable safeguards", which can be met through contractual terms.

Two practical consequences. First, an onshore-only policy is a real constraint: if your organisation requires New Zealand storage specifically, a vendor hosting in Australia does not meet it, however good their controls, and it is better to establish that in the first conversation than the last. Second, residency is only as good as the sub-processor list. A production database in one region and a support-ticketing tool in another is a common and legitimate arrangement, but you should know it. The residency question and the sub-processor question below are really one question asked twice.

Ask, too, what happens if the vendor changes region. A commitment to give reasonable prior notice before any material change to the hosting region is a small clause that protects a large decision.

The controls, one by one

Five areas cover most of what a reviewer needs to establish: encryption, access control, audit logging, backup and recovery, and testing. For each, the useful answer is a specific one — what, where, how often — and the weak answer is an adjective. This section says what to ask and what a specific answer sounds like.

Encryption and key management

Ask three things: is data encrypted in transit for every connection, including the mobile apps; is it encrypted at rest for the database, file attachments and backups; and who manages the keys. The third is the one vendors leave out. Keys managed within the cloud platform under the vendor's management system is a normal, checkable answer. Phrases that borrow prestige from banks or the armed forces are not answers; they have no technical meaning, and a vendor who reaches for them on the security page will reach for them in the incident report.

Access control and authentication

There are two populations to ask about and most conversations only cover one. For your users: is access role-based, how granular are the roles — to module level, or down to individual records — and who administers them, you or the vendor? Is multi-factor authentication available, and can you require it? Are shared logins permitted? (The right answer is no, because a shared login destroys the attribution the audit trail exists to provide.) For the vendor's staff: is internal access on a least-privilege basis, is production access restricted, and is it logged? A vendor that cannot describe its own staff access in a sentence has not thought about it.

Audit logging

Ask whether the platform records who created, viewed or changed a record and when, and whether users — including administrators — can edit that trail. For compliance records this is not a security nicety. It is what makes the record credible in front of an auditor or a regulator two years later. Be precise about the claim you accept: "users cannot edit the audit trail" is a narrow, checkable statement. "Tamper-proof" and "immutable" are broader claims that need a technical explanation before you rely on them.

Backup and recovery

Ask for the backup frequency, the retention period, where backups are stored, whether they are encrypted, and whether a restore has actually been tested. Then ask the question that matters most to you in practice: can you export your own data at any time during the subscription, in a usable format, without asking permission? A vendor's recovery plan protects you against their failures. Your own export protects you against the relationship ending, which is far more likely.

Monitoring and testing

Ask what continuous monitoring exists, whether independent security assessments are carried out, and whether penetration testing and vulnerability assessment happen on a defined cycle. Here, weigh honesty above precision. A vendor that says testing is done "on an ongoing cycle" and offers a summary under NDA is giving you a true, checkable statement. A vendor that names a cadence it cannot evidence is not. What you want is consistency between the page, the questionnaire and the documents — not the most impressive-sounding of the three.

When something goes wrong: breach notification

A vendor's breach-notification commitment exists so that you can meet your own legal duty, which is why the details matter more than the headline number. In New Zealand, the Privacy Act 2020 requires notification to the Privacy Commissioner and affected people "as soon as you are practically able" when a breach has caused or is likely to cause serious harm. In Australia, the Notifiable Data Breaches scheme requires notification to the OAIC and affected individuals where a breach is likely to result in serious harm. Both clocks run against you. The supplier's promise has to arrive early enough for you to act.

Four things need to be in writing:

• The trigger. What counts — unauthorised access to customer data, loss of customer data, or something narrower?
• The clock start. "Within 72 hours of confirming an incident" and "within 72 hours of the incident" are different promises. Neither is wrong, but you need to know which you have.
• The maximum period. A number, not "promptly".
• The content. What you will be told — nature of the incident, data affected, remediation under way — so that you can make your own serious-harm assessment.

Ask also whether the vendor has a documented incident-response process, whether it notifies regulators itself where required, and whether it does a post-incident review with actions tracked to closure. The existence of a written process is a better signal than any adjective describing it.

Sub-processors

Ask for the list of every third party that handles any part of your data — hosting, email delivery, support ticketing, analytics, error monitoring, any AI provider — with the region for each, and ask what obligations bind them. A serious vendor keeps this list, provides it on request, and gives notice of material changes. A vendor who has never compiled it does not know where your data goes.

Two follow-ups earn their place. First, are the sub-processors bound by obligations no less protective than the vendor's own terms with you? Second, if the product has AI features, is your data used to train models, and is that opt-in? An honest answer to the second question is easy to give and easy to check against the privacy policy. Its absence is informative.

How to read a vendor's security page critically

Read a security page by counting what is checkable. Go through it once and mark every sentence that states a specific fact you could verify — a region, a retention period, a certificate number, a notification window, a named sub-processor — and every sentence that is an adjective. A page that is mostly the first kind was written by someone who runs the controls. A page that is mostly the second kind was written by someone who was asked to write a page.

Some patterns to notice:

• Absolutes. Any sentence that promises total safety, rules out compromise altogether, or offers a guarantee. No system can support those claims, and a vendor who makes them either does not know that or hopes you do not. Prefer language like "reasonable efforts" and third-party audit; it is less exciting and more honest.
• Certificates without particulars. "ISO 27001 certified" with no certificate number, body, scope or expiry. Genuine certificates have all four, and a vendor proud of one usually publishes them.
• Provider names in place of regions. "Hosted on AWS" tells you the provider has data centres on several continents. Which one?
• No date. A security page should say when it was last reviewed. One that has never been dated has probably never been reviewed.
• No shared-responsibility section. Good pages say what the customer must do — configure roles, remove leavers, enable MFA, own retention decisions — because the vendor knows it cannot do those things for you.
• No way to report a problem. A named contact for security issues, and a request not to test against other customers' data, are signs of a company that expects to hear from researchers and has decided how to respond.

Comparative claims — that a platform leads its industry or ranks first for security — belong in the adjective column. Nobody has audited the industry. Treat them as a signal about the page, not about the product.

Questions to put in writing

Send these by email, ask for written replies, and keep the replies with the contract. The point of writing is not distrust; it is that a written answer can be checked against the security page, the privacy policy and the certificate, and can be relied on later. Where the vendor offers a completed questionnaire under NDA, take it — it will answer most of these — and use the list to check for gaps.

1. 1.In which country and cloud region are the production database, file attachments and backups stored? Will you give prior notice before changing region?
2. 2.Please provide the certificate number, certification body, accreditation body, scope statement and expiry date for any information security certification, and the link to the public register entry.
3. 3.Is data encrypted in transit for all connections including mobile apps, and at rest for the database, attachments and backups? Who manages the keys?
4. 4.Is access role-based, to what level of granularity, and who administers it? Is multi-factor authentication available? Are shared logins permitted?
5. 5.How is your own staff's access to production controlled and logged?
6. 6.Does the platform record who created, viewed or changed each record and when? Can any user, including an administrator, edit that trail?
7. 7.What is the backup frequency and retention period, where are backups held, and when was a restore last tested?
8. 8.Can we export all of our data, in a commonly used format, at any time during the subscription and within a defined period after it ends? When is it deleted?
9. 9.What is your breach-notification commitment — trigger, clock start, maximum period and content — and is there a documented incident-response process?
10. 10.Please list every sub-processor that handles our data, with its function and region, and describe the obligations that bind it. How will we be told of changes?
11. 11.Is customer data used to train AI models, and if so, is that opt-in?
12. 12.Are independent security assessments and penetration tests carried out, and can you provide a summary of the most recent one under NDA?

A vendor who answers all twelve in writing, and whose answers match its public pages, has given you what you need. A vendor who answers most of them and says plainly which it cannot answer yet is also worth talking to — that honesty is itself evidence. The vendor to be careful with is the one whose answers are longer than the questions and contain no numbers.

What checkable answers look like

Teammate App is our product, so treat this section as what it is: an example of the kind of specific answer the questions above are designed to draw out, offered so you can see the difference between a checkable statement and an adjective — not as a claim that our answers are better than anyone else's. Every item here is stated on our security page and data residency page, where you can read the surrounding detail.

Notice what that list does not contain: no superlatives, no comparisons, and no claim that anything is beyond compromise. It contains things you can check, which is the whole point. Apply the same test to every vendor, including us. The 15 modules, the ISO 45001, 9001 and 14001 alignment, and the offline-capable web, iOS and Android apps are the product; the security answers are the part you verify before you buy the product.

Questions we get asked