Security designed around clinical availability.
Imaging data must be protected without slowing down the people who need it to treat patients.
Identity and access
Role-based access, integrated with your enterprise identity provider, including its multi-factor sign-in.
Encryption
TLS 1.3 between every component and AES-256 for stored data, with keys protected in hardware security modules.
Audit trail
Every access, transfer and administrative change is logged in a standard audit format.
Network segmentation
Scanners, core services and external access paths are kept apart.
Resilience
Backup, replication and tested disaster recovery are part of the design.
Data governance
Retention and handling rules follow your policies and applicable regulations.
Encryption keys held in hardware security modules.
Encryption is only as strong as the protection of its keys. PacsWorks keeps master keys in hardware security modules (HSMs), so they cannot be copied out of software or a server image.
Envelope encryption
Each data set is encrypted with its own AES-256 data key. Data keys are encrypted by master keys that only the HSM can use.
Keys never leave in plain form
Master keys are generated inside the HSM and used there. Servers ask the HSM to unwrap a data key; they never hold the master key.
Rotation and audit
Keys are rotated on a schedule and every use is logged, so key access can be reviewed like data access.
Security at every step of the imaging workflow.
- Scanner to gateway
In transit
DICOM TLS, IHE ATNAStudies travel over TLS from the edge gateway onward, with nodes authenticated to each other.
- Storage
At rest
AES-256, FIPS 140-3Images, reports and backups are encrypted with keys protected in an HSM.
- Sign-in
Access
SSO, IHE XUA/IUAUsers sign in through your identity provider; roles decide what each user sees.
- Sharing
Exchange
DICOMweb, PS3.15Web access runs over HTTPS; research and teaching exports are de-identified.
- Every action
Audit
IHE ATNAAccess, transfers and changes are written to a standard audit trail you can feed to your SIEM.
Standards and regulations we design to.
The medical-imaging, health-software, information-security, cryptography and health-data standards relevant to PACS and cloud imaging in the region.
Medical imaging
| DICOM PS3.15 | NEMA | Security profiles for DICOM: TLS for image transfer, de-identification (Basic Application Level Confidentiality Profile) and the audit message format. |
|---|---|---|
| DICOM PS3.18 (DICOMweb) | NEMA | Web access to images over HTTPS, with access control and audit defined by PS3.15. |
| IHE ATNA | IHE International | Node authentication with mutual TLS and a standard audit trail for every access to patient data. |
| IHE XUA and IUA | IHE International | Passing a user’s identity and authorisation between organisations (SAML) and to web APIs (OAuth 2.0). |
| IHE BPPC | IHE International | Recording patient privacy consent so sharing respects it. |
| MDS2 (ANSI/NEMA HN 1-2019) | NEMA | The standard form manufacturers use to disclose a product’s security controls to hospitals. |
Health software and medical devices
| IEC 81001-5-1:2021 | IEC | Security activities across the health software development lifecycle. |
|---|---|---|
| IEC 80001-1:2021 | IEC | How healthcare organisations manage risk when connecting health software to their networks. |
| ISO 14971:2019 | ISO | Risk management for medical devices, including security-related risks. |
| FDA premarket cybersecurity guidance (2025) | US FDA | Cybersecurity content expected in US submissions, including threat modelling and a software bill of materials. |
| MDCG 2019-16 | EU MDCG | Cybersecurity requirements for medical device software under the EU MDR. |
Information security management and cloud
| ISO/IEC 27001:2022 | ISO/IEC | Information security management system. |
|---|---|---|
| ISO 27799:2025 | ISO | Security controls applied to health information, including images. |
| ISO/IEC 27017 and 27018 | ISO/IEC | Cloud security controls and protection of personal data in public clouds. |
| ISO/IEC 27701:2025 | ISO/IEC | Privacy information management. |
| SOC 2 | AICPA | Independent reporting on security, availability and confidentiality controls. |
| NIST Cybersecurity Framework 2.0 | NIST | Govern, identify, protect, detect, respond and recover. |
| HITRUST CSF and CSA STAR | HITRUST, Cloud Security Alliance | Healthcare and cloud control frameworks used in security assessments. |
Cryptography
| FIPS 140-3 | NIST | Validation of cryptographic modules, including hardware security modules. |
|---|---|---|
| TLS 1.3 (RFC 8446) | IETF | Encryption in transit for DICOM, DICOMweb, HL7 and the viewer. |
| AES-256 (FIPS 197) | NIST | Encryption of stored images, reports and backups. |
Privacy and health-data law
| UAE Federal Law No. 2 of 2019 | UAE Ministry of Health and Prevention | Use of ICT in health fields, including keeping health data in the UAE unless an exception applies. |
|---|---|---|
| UAE PDPL, Federal Decree-Law No. 45 of 2021 | UAE | Personal data protection. |
| ADHICS v2.0 (2024) | Abu Dhabi Department of Health | Healthcare information and cyber security controls for facilities and their technology suppliers. |
| DHA health data protection and NABIDH policies | Dubai Health Authority | Confidentiality, consent, audit and security for Dubai facilities and health information exchange. |
| NCA ECC-2:2024 and CCC-2:2024 | Saudi National Cybersecurity Authority | Essential and cloud cybersecurity controls. |
| Saudi PDPL | SDAIA | Personal data protection, with health data treated as sensitive. |
| Qatar Law No. 13 of 2016 and NIAS | Qatar | Personal data protection and national information assurance. |
| HIPAA Security Rule and GDPR | US HHS, European Union | Security of health information in the US and personal data in the EU. |
PacsWorks is designed to align with the requirements of the standards and regulations listed. Listing a standard is not a claim of certification, accreditation or regulatory clearance. Current certification status and compliance documentation are available on request.
Data residency in the region.
Health-data law across the Gulf restricts where patient data can be stored. In the UAE, Federal Law No. 2 of 2019 on the use of ICT in health fields requires health data relating to care given in the UAE to stay in the country unless an exception applies. Abu Dhabi’s ADHICS standard and Dubai Health Authority policies add security controls that reach technology suppliers, and Saudi Arabia’s NCA controls and PDPL set equivalent expectations.
Hosted PacsWorks components run in an in-country cloud region chosen to meet these requirements, and the hosting region is stated in the contract. On-premises and hybrid deployments keep reading and, where required, the archive inside your own facilities.
Questions we hear.
Are you certified against these standards?
The standards on this page are the ones PacsWorks is designed to align with. Listing them is not a claim of certification. Ask us for current certification status and compliance documentation for your procurement.
Where are encryption keys kept?
Master keys are generated and held in hardware security modules and never leave them in plain form. Data keys that encrypt images and reports are themselves encrypted by those master keys.
Does imaging data leave the country?
Hosted components run in an in-country region chosen to meet health-data residency law, including UAE Federal Law No. 2 of 2019.
Can you complete our security questionnaire?
Yes. We complete MDS2 forms and vendor security questionnaires, and walk your security team through the architecture and data flows.
How are images shared for research or teaching?
Through de-identified export based on the DICOM confidentiality profiles, which remove or replace identifying attributes before images leave the clinical system.
Tell us about your imaging environment.
What you run today, where the bottlenecks are and how you expect to grow. We will come back with an architecture, not a product pitch.