HAKAMA was designed from the ground up for healthcare organisations operating under PDPL, NCA, SDAIA, and SFDA. These are the questions your CISO, legal team, and procurement committee will ask. Here are the answers.
HAKAMA is hosted in a Saudi-region cloud instance. Data residency is by architectural design, not configuration.
ConfirmedHAKAMA operates as a data processor under PDPL. Your organisation remains the data controller. HAKAMA does not determine the purposes or means of processing your data — you do.
ConfirmedNo. Your data is never used to train HAKAMA’s models. This is a contractual guarantee in every agreement. Your policies, governance documents, and compliance data are processed only to produce your outputs.
Contractually guaranteedNo. The Comply, Ready, and Oversee modules operate on governance metadata — document timestamps, completion flags, credential status, accreditation currency, and audit results. HAKAMA does not require access to patient clinical records for its core governance functions.
PHI-free by architectureNo. HAKAMA is administrative compliance infrastructure. It does not diagnose, treat, or direct clinical care. It sits outside the SFDA Software as a Medical Device (SaMD) perimeter under the current regulatory definition.
Outside SaMD scopeYour organisation. Every HAKAMA output — audit findings, compliance scores, Foresight forecasts — is decision-support only. Every output requires human reviewer sign-off. HAKAMA produces defensible compliance artifacts; your team makes compliance decisions.
Human sign-off requiredHAKAMA is aligned to NCA Essential Cybersecurity Controls (ECC). A Data Processing Agreement (DPA) is provided to every customer before go-live, including sub-processor transparency, encryption standards, and access control documentation. ISO 27001 certification is in progress.
NCA ECC alignedWe provide the DPA, architecture diagram, and security pack before any pilot begins — not after you have signed.
Request Security Pack