Data Residency & Compliance Checklist

Why this checklist exists

Most digital health procurement conversations focus on features first and compliance second — usually because compliance questions get asked late, after a vendor has already been shortlisted on functionality alone. That ordering creates risk: a platform that does everything you need but can't answer where your patients' data physically sits, or how it handles a PDPL data-subject request, becomes a much harder problem to solve after a contract is signed than before.

This checklist is vendor-agnostic. Run it against any platform you're evaluating, including this one.

1. Hosting & data residency

• Where is the primary data store physically located, and does that location matter for your organization's internal policy or a Customer Organization's requirements?
• Does the vendor support dedicated or single-tenant hosting, or is all customer data pooled in a shared environment?
• Can the vendor name the specific cloud provider and region, or only a general "cloud-based" description?
• Is there a documented process for changing hosting region if your organization's requirements change?

2. PDPL alignment

• Does the vendor's privacy policy explicitly describe how it handles data-subject rights (access, correction, deletion) consistent with Saudi Arabia's Personal Data Protection Law?
• Who is responsible for responding to a data-subject request — the vendor, or your organization as the entity with the direct patient relationship?
• Does the vendor distinguish clearly between data it controls for its own purposes versus data it processes on your organization's behalf?
• Is there a documented data retention and deletion policy, and does it allow your organization to set retention periods that fit your own regulatory obligations?

3. NPHIES and health data exchange

• Does the platform support NPHIES-aligned data exchange workflows, and can the vendor describe exactly which workflows (eligibility checks, claims, pre-authorization) are covered versus not yet built?
• If NPHIES integration isn't fully built for your specific deployment, what is the realistic timeline and dependency list to get there?
• How does the platform handle data mapping between your internal systems' codes and NPHIES-required formats?

4. Access controls and authentication

• Is access role-based, and can roles be scoped down to the department or branch level, not just organization-wide?
• What authentication methods are supported — password only, multi-factor authentication, single sign-on integration with your existing identity provider?
• Can your organization's admin remove a user's access immediately when someone leaves, without depending on the vendor's support team?

5. Audit logging and monitoring

• Are access events, administrative actions, and configuration changes logged, and for how long are those logs retained?
• Can your organization's compliance team export or review audit logs directly, or does every review require a request to the vendor?
• Is there active security monitoring for anomalous access patterns, or only passive logging after the fact?

6. Sub-processor and vendor transparency

• Does the vendor disclose which third-party services (cloud hosting, SMS/communication providers, payment processors) touch your data?
• Is there a process for your organization to be notified before a new sub-processor is added?

7. Incident response and contractual safeguards

• What is the vendor's documented breach notification timeline, and does it meet or exceed what applicable law requires?
• Does the commercial agreement include a Data Processing Agreement (DPA) or equivalent, separate from the general Terms of Use?
• Are security and compliance commitments described in the contract itself, or only in marketing material?

How CareSync answers these today

CareSync's platform is built to support NPHIES-aligned data exchange workflows and PDPL-aligned data handling principles as part of its architecture, with configurable hosting and data-residency models depending on the specific deployment. That's a description of design intent, not a substitute for asking the questions above directly against your specific deployment — which is exactly the point of this checklist. See the Trust & Security page for the platform's documented approach, and the Privacy Policy and Terms of Use for the governing legal terms.

Related reading

• The 8-Week White-Label Launch Plan — where compliance documentation fits into the rollout timeline
• EHR & HIS Integration Rubric — scoring your existing systems before integration begins