Your hospital may have security policies, annual vulnerability scans and an incident response plan. But can you quickly prove that every system handling health information is covered, its risks have been assessed, and the controls protecting it are actually working?
This is where the ADHICS guidelines can become difficult to apply. A healthcare organisation may have many security controls in place and still struggle to map them to ADHICS V2, collect the right evidence, or know what needs attention first.
ADHICS V2 became effective in August 2024 for entities in Abu Dhabi that generate, access, store, use, process or transmit health information. The standard covers more than documents. It sets requirements for managing information security risks and protecting the confidentiality, integrity and availability of health information.
This guide breaks down what ADHICS V2 means for healthcare organisations, where compliance work can become challenging, and how to approach the requirements without treating security as a paperwork exercise.
What Are the ADHICS Guidelines?
ADHICS stands for Abu Dhabi Healthcare Information and Cyber Security Standard. Issued by the Department of Health (DoH), ADHICS V2 is the DoH cyber security standard Abu Dhabi healthcare entities use to manage information and cybersecurity risks. It applies to healthcare facilities, payers, and healthcare technology and service providers that generate, access, store, use, process or transmit health information.
ADHICS V2 became effective in August 2024. It replaced the earlier ADHICS, IoMT Security and Patient Healthcare Data Privacy standards.
The standard covers more than patient records. It includes medical devices, applications, infrastructure, physical and digital information, and third-party systems used within the Abu Dhabi healthcare ecosystem.
Who Falls Within the ADHICS Scope?
Among the Abu Dhabi healthcare regulations that organisations may need to follow, ADHICS specifically covers information security and privacy requirements for healthcare entities and other covered parties that handle health information. ADHICS V2 applies to in-scope healthcare entities and covers the people, processes, information assets, systems and technologies through which those entities handle health information. This includes staff, contractors and third parties whose access or responsibilities fall within the entity’s security controls.
This means an organisation needs to look at more than its own internal systems. If its healthcare operations rely on third-party applications, medical devices or other systems that handle health information, those systems also need to be considered when assessing its ADHICS requirements.
Organisations searching for a patient data security standard UAE healthcare providers can follow should therefore check which requirements apply in their emirate. ADHICS V2 specifically applies within the Abu Dhabi healthcare sector.
What Does ADHICS V2 Cover?
ADHICS V2 covers the security of health information across its full lifecycle, from creation and access to processing, storage, transmission and disposal. It also covers the systems, applications, medical devices, infrastructure and people that handle or support that information.
The standard is organised into 11 control domains, including human resource security, asset management, physical and environmental security, access control, communications and operations, data privacy and protection, cloud security, third-party security, system development, incident management and information systems continuity.
Confidentiality, Integrity and Availability
ADHICS V2 requires organisations to protect the confidentiality, integrity and availability of health information.
Confidentiality means preventing unauthorised access or disclosure.
Integrity means keeping health information accurate and protected from unauthorised changes. This matters in healthcare because incorrect information can affect clinical decisions and patient safety.
Availability means making health information accessible when authorised users and systems need it. ADHICS also expects organisations to consider continuity when dealing with events such as system failures, natural disasters and denial-of-service attacks.
Governance and Accountability
ADHICS V2 places responsibility on management for implementing and maintaining health information security and privacy. The implementation guideline assigns responsibilities to management, the Information Security Governance Committee, the HIIP Workgroup, the CISO or equivalent security lead, implementation stakeholders, business process owners and asset owners.
The standard also includes governance requirements such as an Information Security and Governance Committee, internal audits, corrective actions and reporting.
Risk-Based Control Implementation
ADHICS V2 does not apply every control in the same way to every organisation. DoH states that control applicability depends on factors such as the entity’s capability, maturity, operational complexity and risk environment. The applicable control category also depends on the type of healthcare entity.
Basic controls form the minimum baseline, while Transitional and Advanced requirements build on the applicable lower-level controls. Healthcare Technology and Services Providers follow the separate Service Provider control category. Applicability should be determined using the entity type and ADHICS control criteria rather than assuming that every organisation has the same control set.
For example, asset inventory is listed under the Basic criteria, while some related controls fall under Transitional or Advanced criteria.
An organisation should identify the controls that apply to its environment before planning implementation.
Statement of Applicability
ADHICS V2 specifically requires an organisation to prepare a Statement of Applicability (SoA). It must list the selected controls, explain why they were selected, record their implementation status and justify any applicable controls that have been excluded.
Why ADHICS Matters for Abu Dhabi Healthcare
For organisations working on healthcare data compliance UAE requirements can vary by emirate and regulatory authority. In Abu Dhabi, ADHICS sets requirements for protecting health information and the systems that handle it, which matters because a cybersecurity incident can affect patient care as well as data.
- Patient privacy: Health information needs protection from unauthorised access or disclosure.
- Patient safety: Unauthorised changes to health information can affect clinical decisions.
- Continuity of care: Systems and information need to remain available during disruptions.
- Accountability: ADHICS assigns security responsibilities across management, security roles, business owners and asset owners.
ADHICS V2 Compliance Checklist
The checklist below combines ADHICS V2 requirements with implementation practices drawn from the DoH implementation guideline. The exact applicability of each control depends on the entity type and ADHICS control category. Organisations should map the checklist to the applicable ADHICS controls before treating an item as a mandatory requirement.
1. Define Scope and Inventory Assets
Your inventory should cover:
| Asset area | Examples |
| Information | Patient and operational information in physical or digital form |
| Software | EMR, laboratory, pharmacy, imaging and business applications |
| Biomedical assets | Connected medical devices and equipment |
| Infrastructure | Servers, networks, storage and other information systems |
| Cloud services | Hosted systems, SaaS platforms and cloud infrastructure |
| Third parties | External systems and services that connect to or process information |
ADHICS V2 implementation guidance requires an asset inventory covering information, hardware, biomedical and software assets. It also requires an owner to be assigned to each asset.
Do not limit the inventory to systems managed directly by IT. Include assets used by clinical teams, connected medical devices, applications and third-party systems that support healthcare operations.
2. Establish Governance Structure
ADHICS V2 gives information security responsibilities to specific roles rather than leaving security with the IT team alone.
The implementation guideline assigns security responsibilities across management, the security governance structure, business process owners and information asset owners. Asset owners are responsible for applying the policy within their area and ensuring that assets are properly classified.
At a minimum, check that your organisation has:
- A named person responsible for information security
- Clear responsibilities for business and asset owners
- Defined ownership for information assets
- A management process for security policies and controls
- A defined process for tracking security issues, corrective actions and risk decisions
The people named in the policy should also be carrying out the responsibilities assigned to them.
3. Assess and Document Risks
ADHICS V2 treats health information security as a risk-management issue. Your risk assessment should consider how threats, weaknesses and operational failures could affect the confidentiality, integrity and availability of health information. The ADHICS V2 Implementation Guideline states that an entity should conduct an Information Security Risk Assessment at least annually or whenever changes to its environment may affect its risks.
Start with questions such as:
- Which information assets could be exposed, changed or made unavailable?
- Which clinical or business services depend on those assets?
- What security weaknesses could affect them?
- Which third parties can access or process the information?
- What controls are already in place?
- What risks remain after those controls are applied?
Record the results in a risk register with the risk description, owner, current status, treatment plan and review information.
For example, an unsupported medical device connected to a clinical network may create a different risk from an outdated office application. The assessment should capture how each weakness could affect the organisation and the health information or services it supports.
4. Implement Access Control
Access should be based on what a person needs to do their job, not simply on their department or job title. ADHICS V2 specifically calls for need-based and role-based access, along with controls for granting, authorising, reviewing and revoking access.
A practical access-control review should cover:
- Unique user accounts: Each user should have an individual identity. Shared accounts make it harder to know who accessed or changed information.
- Role-based access: Give users only the permissions needed for their role. A clinician may need access to clinical systems without needing access to finance systems.
- Access reviews: Review user permissions and remove access that is no longer needed, especially after role changes or when someone leaves.
- Privileged access: Apply stronger controls to administrator and other high-privilege accounts.
- Third-party access: Limit vendor access to what is needed for the service and keep appropriate records of that access.
- Medical devices: Include connected medical devices and equipment in access-control decisions where they support or process health information.
Healthcare organisations should also have a controlled process for emergency access. If an authorised user needs information that would normally be restricted, the access should be recorded and reviewed afterwards.
5. Conduct Security Testing
Security testing is not the same as running a vulnerability scanner once a year. The ADHICS V2 implementation guidance includes annual vulnerability assessment and penetration testing requirements.
ADHICS V2 requires entities to establish yearly schedules for vulnerability assessment and penetration testing of the applicable systems and environments, including entity infrastructure, internet-accessible web and mobile applications, and connected medical devices. It also requires security testing and authorization for new deployments and changes before production rollout.
The two activities serve different purposes:
| Testing | What it helps with |
| Vulnerability assessment | Finds known vulnerabilities, missing security fixes and other weaknesses |
| Penetration testing | Uses manual and automated techniques to test whether weaknesses can actually be exploited |
For healthcare environments, testing may also need to consider medical devices and equipment where they fall within the assessment scope. DoH guidance also calls for mitigation measures to be revalidated.
One point is easy to miss here. The assessment report itself contains sensitive security information. ADHICS V2 requires entities to ensure that assessment data is not retained by third-party assessors beyond the engagement and that relevant information and assessment outcomes are erased from the assessor’s assets and environment after the assessment.
6. Secure Software Development
Healthcare organisations that develop or customise applications need security controls during development, not only after an application reaches production.
ADHICS V2 implementation guidance includes security requirements early in software development, security checkpoints during project milestones, secure repositories and version control, secure coding practices and controls for external parties involved in development.
For an application such as a patient portal or healthcare management system, this can include:
- Reviewing authentication and authorisation requirements before development starts
- Protecting source code and controlling who can access it
- Using secure coding practices
- Testing security before production release
- Keeping development, testing and production environments properly separated
- Applying change management to security fixes and software changes
- Requiring external developers to follow the organisation’s security rules where applicable
7. Protect Data in Transit and at Rest
ADHICS V2 requires organisations to protect health information when it is stored and when it moves between systems. The implementation guidance also covers encryption for cloud-hosted data and says encryption keys must be secured.
Practical implementation checks
- Data at rest: Encrypt sensitive health information stored in databases, servers, backups and other storage systems where required.
- Data in transit: Use secure protocols such as HTTPS and TLS when information moves between systems or across networks.
- Encryption keys: Keep keys separate from application code and configuration files, restrict access to them and protect them from unauthorised use.
- Cloud data: Confirm that cloud providers protect stored and transmitted information using appropriate encryption controls.
- Backups: Apply suitable encryption and access controls to backup data, including copies stored outside the organisation.
8. Manage Medical Devices and Connected Technology
Medical-device security is not a separate consideration outside ADHICS V2. The earlier IoMT Security Standard has been retired and its requirements are addressed within ADHICS V2. A medical device review should consider:
- What devices are connected to the organisation’s network?
- What information does each device collect, store or transmit?
- Which systems or vendors can connect to the device?
- Who is responsible for maintaining it?
- How are vulnerabilities, updates and security issues handled?
- What happens if the device or its supporting system becomes unavailable?
Do not leave a medical device out of the security programme simply because a clinical or biomedical team manages it.
Where a device depends on a manufacturer or other third party, the organisation should also understand how security updates, vulnerability handling, access and incident reporting are managed.
9. Implement Monitoring and Incident Response
ADHICS V2 includes requirements for logging, monitoring, incident management and the protection of evidence.
At a minimum, your incident process should define:
| Area | What to establish |
| Logging | Which systems and security events are logged |
| Monitoring | Who reviews alerts and how suspicious activity is escalated |
| Response | Who investigates and contains an incident |
| Evidence | How logs and other evidence are preserved |
| Reporting | When and how DoH must be notified |
| Recovery | How affected systems are restored and reviewed |
ADHICS V2 requires organisations to detect, report, prioritise and handle breaches involving personal or health information. The organisation must notify DoH within the timelines set in the applicable incident‑reporting matrix. The 72-hour requirement applies specifically to submission of the Data Breach Form. It should not be presented as a universal 72-hour deadline for the initial incident notification, which is governed by the applicable DoH incident-reporting matrix.
Your incident response plan should identify who decides whether an incident is reportable and who contacts DoH. It should also state what information must be collected and how evidence will be preserved.
The DoH AAMEN programme also works with the Abu Dhabi Healthcare CERT on areas including cyber incident response and related cybersecurity capabilities.
10. Plan for Business Continuity and Disaster Recovery
A healthcare organisation needs to know how it will keep critical information systems and services running when something goes wrong. ADHICS V2 requires an Information Systems Continuity and Recovery Plan covering critical information assets and services, including systems, medical devices, equipment and applications within scope. The plan should also set recovery strategies, assigned responsibilities and escalation procedures.
| Area | What to document |
| Critical services | Which healthcare services depend on each system |
| Recovery time | How quickly each critical service needs to return |
| Data recovery | How much recent data the organisation can afford to lose |
| Backups | What is backed up, how often and where it is stored |
| Recovery roles | Who activates the plan and who restores each system |
| Testing | How the organisation will test continuity and recovery plans |
ADHICS guidance also calls for backup policies and continuity testing.
11. Manage Third-Party Risk
ADHICS V2 includes third-party security within its control framework, so keep a record of the external parties that can access, process, store or support health information and critical systems.
For each higher-risk supplier, consider checking:
- What information or systems can the supplier access?
- Where is the information stored and processed?
- What security controls does the supplier maintain?
- How are security incidents reported?
- How are vulnerabilities and security updates handled?
- What happens to the information when the contract ends?
- What evidence can the supplier provide about its security controls?
A SOC 2 report, ISO 27001 certificate or security assessment may help with this review, but these should be treated as evidence to consider, not as automatic proof that a supplier meets ADHICS requirements.
Contract terms should also cover security responsibilities, information protection, incident reporting and access requirements. The level of review should reflect the supplier’s access, the information involved and the risk it creates.
12. Train Staff and Measure Compliance
Security controls can fail if staff do not know what is expected of them. ADHICS V2 includes security awareness and training as part of its information security requirements, and DoH has also established the Abu Dhabi Healthcare Cyberlearning Programme to build cybersecurity awareness among healthcare professionals.
Training should cover the issues people are most likely to face in their roles, such as:
- Protecting health information
- Recognising and reporting suspicious activity
- Handling passwords and access credentials
- Reporting security incidents
- Following the organisation’s information security policies
Training should not end with a completion percentage. Use the results of security exercises, incident reviews, access reviews and vulnerability trends to see where the programme needs improvement.
Evidence Organisations Should Maintain for an ADHICS Assessment
The exact evidence requested will depend on the applicable controls and assessment scope. Your organisation should also be able to produce records that support how its security controls are being implemented and maintained.
Some useful evidence includes:
| Area | Evidence to maintain |
| Governance | Security policies, Information Security Manager records, security committee minutes, risk register, security budget and management reports |
| Technical controls | Asset inventory, risk assessments, vulnerability assessment and penetration testing reports, remediation records, access reviews, encryption records and security logs |
| Incident and resilience | Incident response plan, investigation records, DoH breach notifications where applicable, continuity and recovery plans, backup testing and recovery exercise results |
| Third parties | Supplier risk assessments, security assessments, contracts with security clauses and vendor review records |
| Training | Training completion records, awareness material and records of the training provided |
DoH’s ADHICS implementation guideline includes internal audits to check whether applicable controls have been implemented and maintained effectively. It also requires documentary evidence when an organisation marks an applicable control as not applicable.
Keep testing and review records current. Where the applicable controls require it, ADHICS V2 calls for annual vulnerability assessment and penetration testing, with additional testing after major changes or when new systems or applications are introduced. The ADHICS V2 Implementation Guideline states that access reviews should occur every three months for critical systems and at least annually for other systems.
Potential ADHICS Compliance Gaps to Check
Knowing where ADHICS work often falls short can help healthcare organisations focus their efforts before an assessment.
Incomplete Asset Inventory
An organisation may have an inventory of its main systems but miss older applications, connected medical devices or third-party services that handle health information. ADHICS requires organisations to maintain asset inventories, including medical devices and equipment.
Weak Governance and Unclear Ownership
Policies may exist, but responsibilities are not always followed in practice. Risk registers may not be updated, security actions may remain open, or nobody may be clearly responsible for fixing a finding. ADHICS gives defined security responsibilities to management, security roles, business owners and asset owners.
Limited Testing of Medical Devices
Some organisations focus their testing on servers, applications and networks while giving less attention to medical devices. ADHICS specifically requires organisations to maintain an inventory of medical devices and equipment, assign access responsibilities and manage their security risks.
Inadequate Vendor Risk Management
Cloud platforms, application providers and medical device suppliers can have access to health information or support important systems. ADHICS requires security due diligence before appointing third parties, security requirements in agreements and ongoing monitoring of third-party services.
No Incident Response Capability
Having an incident response document does not mean the organisation is ready to use it. ADHICS requires incident management roles, response procedures and periodic testing of incident response capabilities. If these processes are not tested, teams may struggle when an actual incident occurs.
Missing Evidence for Audit
An organisation may have completed security testing, fixed vulnerabilities and reviewed user access, but still struggle to produce the records.
Without those records, it can be difficult to show that the control was implemented, reviewed and maintained.
How Qualysec Helps Healthcare Organisations with ADHICS
ADHICS requires more than completing security testing. Healthcare organisations also need to know what to test, what the findings mean for their environment, and whether the fixes actually work.
Qualysec helps healthcare organisations with security assessments across:
- Web applications and patient portals
- APIs and healthcare integrations
- Mobile applications
- Cloud and network infrastructure
- Connected medical devices and IoT environments
The testing combines automated tools with manual security testing to look for weaknesses that a basic scan may miss. Qualysec also provides healthcare device penetration testing covering areas such as device firmware, communication protocols, APIs and supporting systems.
Findings are documented with remediation guidance, and Qualysec can retest the affected systems after fixes are applied to verify that the issues have been resolved.
This gives healthcare teams testing records, remediation guidance and retesting results they can retain as part of their security evidence.
In one Qualysec healthcare security assessment, the scope included three public-facing websites and network infrastructure, resulting in 29 identified vulnerabilities.
Conclusion
ADHICS compliance is about protecting health information while keeping the systems that support healthcare operations secure and available. It requires clear scope, risk assessment, appropriate controls, security testing and evidence that those controls are being maintained.
Do not leave evidence collection until an assessment is approaching. Testing reports, risk records, remediation updates and governance records should become part of the normal security process.
If you need help assessing your healthcare environment against ADHICS guidelines, Qualysec provides vulnerability assessments, penetration testing and remediation validation.
Frequently Asked Questions
1. What are ADHICS guidelines?
ADHICS stands for Abu Dhabi Healthcare Information and Cyber Security Standard, issued by the Department of Health. ADHICS V2 became effective in August 2024 and sets information security requirements for entities handling health information in Abu Dhabi.
2. Who must comply with ADHICS?
ADHICS applies to entities in Abu Dhabi that generate, access, store, use, process or transmit health information. This includes healthcare facilities, payers, and healthcare technology and service providers covered by the standard.
3. Does ADHICS require penetration testing?
ADHICS V2 includes vulnerability assessment and penetration testing requirements, depending on the controls applicable to the entity. The implementation guidance includes an annual testing schedule, along with testing for new deployments and changes before they enter production. The assessment scope can include systems, networks, infrastructure, internet-accessible web and mobile applications, and connected medical devices.
4. What’s the difference between Basic, Transitional and Advanced ADHICS control categories?
Basic, Transitional and Advanced are control levels used within ADHICS V2. The minimum applicable level depends on the type of healthcare entity, while specific control requirements can also depend on factors such as capability, maturity, operational complexity and risk.
5. How long does ADHICS implementation take?
ADHICS does not set a fixed implementation period such as six or twelve months. The time needed depends on the organisation’s existing controls, maturity, scope, risks and the ADHICS requirements that apply to its environment.
6. What is the breach notification requirement under ADHICS?
ADHICS V2 requires incidents to be reported to DoH within the timelines set in the applicable incident-reporting matrix. A Data Breach Form must also be shared with DoH within 72 hours of acknowledging the incident, with further updates as required.
