Zanda is ISO 27001 certified. This article explains what the certification actually changes about how Zanda runs day to day, how those controls are tested rather than just documented, and what to point to if a client, insurer, or auditor asks how you know your data is safe with Zanda.
How ISO 27001 shows up in daily operations
Many of the day-to-day practices at Zanda exist because they are good security practices in their own right, and they also form part of the ISO 27001 program. The certification audits those practices: Zanda documents its processes, follows them, and retains evidence that the relevant actions were completed.
Policies and staff training. Policies and procedures are held in an information management system, reviewed regularly, and require sign-off. The security and privacy team develops, updates, and improves those policies, with review and approval built into monthly security review meetings. Every team member acknowledges the policies annually as part of their training, and everyone at Zanda completes formal training on data privacy, information privacy, and security, with evaluations to check the material was understood. Incident exercises are part of that regular training too, giving the team practice at responding before a real incident happens. Policy sign-off records and training completion evidence are documentation that the regular ISO 27001 audits inspect, sampling records and reviewing notes to confirm the reviews and training actually took place.
Managing and reviewing access. A security system documents, monitors, and manages each team member’s access to internal systems and software, recording who has access to each application and at what level. A team member can request access, but an application manager responsible for that application must approve it before access is granted. Existing access is reviewed regularly throughout the year to confirm people still need what they have, and those reviews are signed off by the application manager. When someone leaves Zanda, that triggers access reviews across every application they had access to, and the resulting changes are recorded with supporting evidence, typically a screenshot. Both the regular access reviews and the leaver-triggered changes are checked as part of the annual ISO 27001 audit: auditors examine a sample of access changes and their supporting evidence to confirm the process was actually followed, not just documented.
Secure software development. Every software change is checked against an automated test suite containing tens of thousands of tests before release. For every update, an entirely new Zanda environment, including servers and a database, is created to test it, many times a day. This validates the change itself, and because the environment is built from infrastructure defined as code, it also exercises the code that builds that infrastructure. This process, and the records it produces, are documentation the regular ISO 27001 audits review to validate and check that secure development practices are being followed in practice, not only on paper.
Monitoring components and vulnerabilities. Zanda is built from code written in-house and components from other providers. The components in use, and the channels through which their providers disclose security issues, are both monitored, and affected software is updated quickly once an issue is announced, since new releases often carry important security fixes. This monitoring work is documented, and that documentation is inspected as part of the regular ISO 27001 audits, which check that the monitoring and update process is actually being carried out.
Risk and supplier review. An information security team meets monthly to assess and review the company’s risk register, keeping the team informed and able to direct that a risk be addressed if it reaches an unacceptable level. New vendors go through an onboarding process that assesses what data they need to access and how they handle and protect it, and suppliers are reviewed on an ongoing basis to confirm they continue to meet the required standards. A register of these suppliers is maintained and is available to customers on request. The monthly risk review notes and the supplier onboarding and review records are documentation the regular ISO 27001 audits sample and check, confirming these reviews happened and were acted on rather than just scheduled.
Daily maintenance without disruption. Maintenance and updates are performed every day, but that does not mean the system goes offline every day. Redundancy and scalability built into the system let one part keep operating while another is updated, then switch over, so almost all of that daily maintenance happens without customers noticing. The need to take the system fully offline for maintenance is minimal: actual downtime for planned maintenance is measured in minutes per year, and taking the system offline is a rare event. Like the other practices in this section, maintenance records are documentation the regular ISO 27001 audits can review to confirm the process matches what is documented.
How Zanda tests that these controls actually work
Documenting a control is not the same as knowing it works. Zanda tests its security and reliability controls on a recurring basis, rather than relying on the fact that they are written down.
Annual external penetration testing. Once a year, an external company attempts to access systems and information it should not be able to reach, then reports its findings and recommended improvements. Zanda reviews, implements, and releases the changes, and the same testers later review the implementation and record whether each recommendation was addressed satisfactorily.
Weekly backup restore tests. Every week, a full backup restore is performed, and the restore is checked to confirm it succeeded and that the expected information is present, giving recurring evidence that restoration works.
An annual disaster recovery exercise. Once a year, as part of the ISO 27001 program, Zanda runs a full disaster recovery exercise: restoring data and building a complete new system from infrastructure defined as code. The exercise records how long the recovery takes, and the restored system is validated using the same automated test suite used before every release.
Incident and monitoring practice. Extensive logging and firewalls flag suspicious traffic for investigation, and the incident-response process itself is exercised regularly through training, not only when something real happens.
Independent audits. A formal internal audit is run annually, with help from an external consultant, a couple of months ahead of the annual external audit; the external audit also validates that the internal audit process itself is sound. External auditors sample evidence that documented processes are actually being followed, for example checking a sample of access changes and their supporting evidence, or reviewing incident documentation. Improvements identified by an audit are assigned an owner, broken into tracked tasks, and where a fix requires a software change, traced through the resulting code change and its deployment.
Responding to and learning from incidents
The threshold for treating something as an incident is deliberately low: if something is affecting customers, or could potentially affect them, the incident management process starts, even before any customer has reported a problem. Monitoring that flags an anomaly can be enough to begin it.
Zanda aims to act quickly, share information, and learn from what happened, keeping customers updated as the incident unfolds. See Reliability and Availability for the full incident response process, including how status updates are published and how to get notified of them.
After every incident, a retrospective looks back at the documentation, the internal and external communication, and how well the response matched the relevant policy, then identifies what would help handle a similar situation better next time. Every incident and its retrospective are documented, and that documentation is itself audited as part of the information security program.
What to point to if you are asked whether your data is safe with Zanda
If a client, insurer, or auditor asks how you know your data is safe with Zanda, these are the pieces that, together, answer that question:
- Public certifications and documentation. The Healthcare Data Security at Zanda page lists security and privacy certifications and offers downloadable security documents, alongside help center articles explaining the approach to encryption, access controls, infrastructure, and operational practices.
- Encryption. Customer data is encrypted both at rest and in transit, using encryption keys unique to each customer. Those keys are stored in a separate system with tightly managed, logged access.
- Access controls with evidence behind them. Access to internal systems is requested, approved by an application manager, and reviewed regularly throughout the year; access is reviewed again whenever someone leaves, with supporting evidence recorded; and auditors sample that evidence annually to confirm the process is followed. See Zanda Staff Access to Your Account and Client Data.
- Independent assessment. An annual external penetration test, with a documented follow-up review of the fixes; an annual internal audit backed by an external consultant; and the external audit that validates both.
- Backup and recovery evidence. Weekly backup restore tests and an annual disaster recovery exercise that rebuilds a complete system from infrastructure defined as code and validates it with the same automated test suite used before every release. See Data Protection, Backups, and Disaster Recovery.
- Monitoring, incident response, and communication. Ongoing log monitoring, a low threshold for activating incident response, and a documented communication and retrospective process for every incident.
- Operating history. Zanda has been operating since 2010 and has maintained at least 99.9% uptime across its lifetime and in every individual year, measured through logging and excluding planned maintenance.
Frequently Asked Questions
Can Zanda give me the exact date of the last backup restore test, or specific RTO/RPO figures?
Not from this article. This page explains what is regularly tested and how; account-specific evidence such as a signed attestation, the date of the most recent restore test, or the recovery time and recovery point objectives achieved goes beyond what is published here. See Responding to Security and Data Residency Audits for how to request that directly from Zanda.
Where can I see the vendor and supplier list?
A register of the suppliers Zanda reviews and onboards is maintained and made available to customers on request. Contact Zanda support to ask for it.
Does “at least 99.9% uptime” include planned maintenance?
No. Planned maintenance is excluded from the uptime calculation, and in practice there is very little of it to exclude. Maintenance and software updates happen every day, but redundancy lets one part of the system keep running while another part is updated, so almost none of that daily work requires taking anything offline. Actually taking the system offline for maintenance is a rare event, and the resulting downtime is measured in minutes per year rather than hours.