ADHICS Compliance UAE: Healthcare Security Requirements

Important ADHICS and legal note
ADHICS is an Abu Dhabi healthcare security standard. Applicability can depend on the organization’s Department of Health licence, role, systems, contracts, and handling of health information. Confirm the current official standard, circulars, and implementation guidance before relying on version-specific requirements. This guide is educational and is not legal advice. Security testing can support selected technical controls, but it does not independently establish compliance.

Key Takeaways

ADHICS is the Abu Dhabi Healthcare Information and Cyber Security Standard issued for the Abu Dhabi healthcare sector.
This guide addresses ADHICS V2. Organizations should confirm the current official document, effective date, and any later amendments before relying on version-specific requirements.
Applicability should be confirmed by licence type, healthcare role, data-processing responsibilities, contractual obligations, and the organization’s relationship with regulated healthcare services in Abu Dhabi.
Readiness requires governance, risk management, asset and data visibility, technical safeguards, operating evidence, incident preparedness, continuity, supplier oversight, and management review.
A written policy is not enough. Assessors typically need evidence that controls are implemented, used, reviewed, tested, and improved.
Vulnerability assessment and penetration testing can support technical assurance when required or appropriate, but they cover only an approved scope at a point in time.
Patient safety, clinical continuity, third-party authorization, synthetic test data, secure evidence handling, and emergency-stop procedures should shape healthcare testing.
ISO 27001, HIPAA, the UAE PDPL, NIST, OWASP, and PCI DSS may provide useful context, but none should be treated as an automatic substitute for ADHICS.

Quick Answer: What Is ADHICS Compliance?

ADHICS compliance means establishing and maintaining the governance, security controls, operating processes, and evidence required by the Abu Dhabi Healthcare Information and Cyber Security Standard for the parts of an organization that fall within its scope. The standard is associated with the Abu Dhabi Department of Health and is intended for the emirate’s healthcare environment; it should not be described as a single UAE-wide rule. An organization should first confirm whether the current standard applies to its licence, services, systems, suppliers, and processing of health information. Compliance is broader than a policy library, vulnerability scan, or penetration test. It requires controls to be implemented, operated, reviewed, evidenced, and improved. Technical testing can support selected requirements by showing how specific systems resist realistic attack paths, but the test report is only one part of the assurance record.

What Is ADHICS?

ADHICS stands for the Abu Dhabi Healthcare Information and Cyber Security Standard. It is a sector-specific framework intended to protect healthcare information, technology, and service delivery in Abu Dhabi. Unlike a generic cybersecurity checklist, it brings governance, privacy, operational security, technical safeguards, continuity, supplier risk, and evidence requirements into a healthcare context.

Organizations should rely on current Department of Health materials for legal scope, control applicability, reporting obligations, data-location requirements, and assessment terminology. Third-party guidance can help explain implementation, but it should not replace the official standard. Readers should distinguish official requirements from practical security interpretation and editorial recommendations.

Who Issues and Oversees ADHICS?

The Abu Dhabi Department of Health is the relevant healthcare authority for ADHICS. Organizations should use current DoH materials to confirm the responsible programme, document owner, and assessment process. A testing provider, consultant, or auditor should not claim authority to issue regulatory approval unless that role is formally recognized by the relevant authority.

Who May Need to Comply?

The safest approach is to treat applicability as a scoping question, not as a marketing statement. Direct obligations may depend on the entity’s Abu Dhabi healthcare licence. Contractual or supply-chain obligations may also affect technology providers, hosting providers, laboratories, payers, telehealth platforms, and other organizations that handle or support regulated health information. A provider operating outside Abu Dhabi should not assume ADHICS applies merely because it works in healthcare; equally, a supplier may have contractual control obligations even when it is not directly licensed by the Department of Health.

Organization or Role	Potential Applicability	What Must Be Verified
Licensed hospitals, clinics, pharmacies, and laboratories	Likely direct applicability	Confirm current licence category and current ADHICS applicability matrix.
Healthcare professionals and workforce members	Usually covered through organizational controls	Confirm individual obligations versus the licensed entity’s obligations.
Payers, insurers, and third-party administrators	Potential direct or category-based applicability	Verify against the current V2 scope rather than relying on older FAQs.
Telehealth and digital-health providers	Potential direct or contractual applicability	Confirm licensing status, data flows, hosting model, and customer contracts.
Cloud, hosting, and managed-service providers	Often contractual or supply-chain applicability	Confirm whether the provider is directly regulated and what customer controls flow down.
Medical-device and clinical-technology vendors	Variable	Confirm whether the device, service, or integration falls within the organization’s current control scope.
Organizations operating only in another emirate	Not automatically in scope	Confirm the local health authority and federal legal requirements that apply.

Current ADHICS Version

This guide addresses ADHICS V2. Standards, circulars, and implementation guidance can change, so organizations should confirm the current official Department of Health publication, effective date, applicability matrix, and any later amendments before applying version-specific requirements.

Item	Reader Guidance	Action
Official title	Abu Dhabi Healthcare Information and Cyber Security Standard (ADHICS).	Confirm the wording on the current official Department of Health document.
Current version	This guide addresses ADHICS V2.	Check whether a later version, amendment, or transition notice exists.
Publication and effective date	Use the dates shown in the current official publication.	Record the document version, effective date, and retrieval date.
Applicability matrix	Requirements may differ by entity type, licence, role, and control category.	Use the current applicability matrix; do not rely on superseded categories.
Assessment terminology	Use the authority’s current terms for assessment, audit, self-assessment, or attestation.	Avoid substituting commercial terminology for official terminology.
Certification terminology	Do not assume that an “ADHICS certification” scheme exists.	Confirm the current official assessment and recognition process.
Related circulars	Circulars and implementation notices may affect scope, reporting, or transition requirements.	Review the current official circulars and retain retrieval dates.

ADHICS Requirements at a Glance

ADHICS readiness is best understood as a system of related controls. The exact domain names and control references should come from the current official standard. The table below is an implementation-oriented summary, not a substitute for the control catalogue.

Control Area	Purpose	Example Evidence	Typical Owners
Governance and risk	Define accountability, policy ownership, risk treatment, exceptions, and management oversight.	Approved policies; risk register; committee minutes; exception records.	Executive leadership, CISO, risk and compliance
Asset and data visibility	Identify systems, applications, devices, suppliers, data stores, and data flows.	Asset register; data-flow diagrams; ownership records; classification scheme.	IT, data owners, clinical technology
Identity and access	Control user, privileged, service, emergency, remote, and third-party access.	Access matrix; MFA configuration; access reviews; joiner/mover/leaver records.	IT security, IAM, HR
Infrastructure and endpoints	Secure networks, endpoints, wireless, remote access, configurations, and legacy systems.	Network diagrams; firewall reviews; patch reports; endpoint status; exceptions.	Network, infrastructure, security operations
Applications, APIs, and mobile	Integrate security into design, development, change, deployment, and maintenance.	Secure SDLC records; code review; test reports; dependency records; remediation tickets.	Engineering, AppSec, product owners
Cloud and suppliers	Manage shared responsibility, contracts, access, monitoring, resilience, and data handling.	Cloud inventory; contracts; architecture; access logs; supplier reviews; exit plans.	Cloud, procurement, legal, GRC
Monitoring and incident response	Collect useful logs, detect events, escalate incidents, preserve evidence, and report where required.	Logging standards; SIEM use cases; incident plans; tickets; exercises; notification records.	SOC, incident response, legal and privacy
Vulnerability management and testing	Identify weaknesses, prioritize risk, test selected controls, remediate, and retest.	Scan reports; penetration-test reports; tickets; risk acceptances; retest evidence.	Security, engineering, system owners
Continuity and recovery	Protect critical healthcare services and validate recovery arrangements.	BCP/DR plans; backup tests; recovery exercises; dependency maps; lessons learned.	Business continuity, IT, clinical operations
Workforce and physical security	Address personnel, awareness, acceptable use, secure areas, equipment, and media.	Training records; acknowledgements; access logs; visitor records; disposal records.	HR, facilities, security
Privacy and health-information protection	Protect health information throughout its lifecycle and coordinate with applicable privacy law.	Privacy policies; processing records; access logs; impact assessments; retention evidence.	Privacy, legal, compliance, data owners

How to Prepare for an ADHICS Assessment

A readiness programme should move from scope to evidence, not from document templates to a superficial checklist. The sequence below is a practical readiness model rather than an official audit process. Map each stage to the current applicable ADHICS controls and any authority-specific submission requirements.

Stage	Key Activities	Evidence Produced
1. Confirm applicability	Identify the current version, regulated entities, sites, services, systems, data, and contracts.	Applicability memo; approved scope statement.
2. Map requirements	Map current official controls to policies, systems, owners, and evidence sources.	Control matrix; ownership matrix.
3. Inventory assets and data flows	Identify applications, APIs, cloud services, devices, integrations, and sensitive data paths.	Asset register; data-flow maps; system diagrams.
4. Assess gaps and risk	Compare control design and operating evidence with the applicable requirements.	Gap report; risk register; treatment plan.
5. Implement and operate controls	Close design gaps and generate repeatable operating evidence.	Policies; configurations; tickets; logs; training records.
6. Validate effectiveness	Use reviews, audits, scanning, penetration testing, exercises, and recovery tests as appropriate.	Assessment reports; test results; exercise records.
7. Remediate and retest	Assign owners, fix issues, document exceptions, and verify selected corrections.	Remediation tickets; risk acceptance; retest report.
8. Management review	Present residual risk, evidence gaps, overdue actions, and exceptions to accountable leaders.	Management pack; minutes; approvals.
9. Prepare the assessment package	Organize current, traceable evidence without overstating completeness.	Evidence index; control cross-reference; submission package.
10. Maintain the programme	Review after major changes, incidents, regulatory updates, or material supplier changes.	Change records; periodic reviews; updated risk treatment.

The ADHICS Readiness Evidence Model

The following five-layer model is a DeepStrike editorial framework. It is not an official Department of Health model and must not replace the actual ADHICS control structure. Its purpose is to prevent a common failure: treating a policy, screenshot, or test report as complete proof of compliance.

Evidence Layer	Core Question	Examples	Limitation
1. Governance intent	Are policy, accountability, ownership, and risk decisions formally approved?	Policies, roles, committee charters, risk appetite, exceptions.	Intent does not prove operation.
2. Control implementation	Are the required administrative and technical controls configured?	Configurations, architecture, access settings, tooling, contracts.	A screenshot may be outdated or incomplete.
3. Operational evidence	Are the controls being used consistently over time?	Logs, tickets, reviews, approvals, training, supplier records.	Evidence can exist without proving effectiveness.
4. Effectiveness validation	Do selected controls resist realistic failure or attack scenarios?	Risk assessments, audits, scans, penetration tests, exercises.	Validation is limited by scope, timing, and method.
5. Remediation and assurance	Are weaknesses owned, corrected, retested, and reported?	Corrective actions, retests, residual-risk records, management reports.	Closure of known issues does not eliminate future risk.

Security Control Areas and Practical Evidence

To keep the guide focused on search intent and implementation value, the requirements below are grouped into five practical clusters. The structure preserves the evidence and ownership guidance readers need without repeating each control domain as a separate mini-guide.

1. Governance, Risk, Assets, and Data

Start with accountability and visibility. Define who owns the security programme, each system, each dataset, supplier relationships, risk acceptance, and control evidence. Maintain an asset register that covers infrastructure, applications, APIs, cloud services, mobile apps, identity services, connected devices, integrations, and critical third parties. Map how health information is collected, accessed, transferred, backed up, retained, and disposed of. Incomplete inventory creates compliance and testing blind spots.

Evidence: approved policies, risk register, asset register, data-flow diagrams, classification scheme, exception records, committee minutes.
Practical test: select a sample of critical systems and trace each one from ownership and data flow to access, logging, supplier, recovery, and testing records.
Important caveat: do not label an organization compliant because its policy library is complete; operating evidence is required.

2. Identity, Infrastructure, and Endpoint Security

Identity and infrastructure controls should reduce unauthorized access and limit the effect of a compromised account or device. Review privileged access, emergency access, remote access, service accounts, third-party access, segregation of duties, joiner/mover/leaver processes, MFA, network segmentation, patching, secure configuration, endpoint protection, wireless security, and compensating controls for legacy clinical systems.

Evidence: access reviews, privilege records, MFA configuration, firewall and segmentation reviews, patch reports, endpoint coverage, approved legacy-system exceptions.
Healthcare consideration: emergency or break-glass access may be clinically necessary, but it should be controlled, monitored, reviewed, and tested.
Use the review interval stated in the applicable control and risk process; do not assume that one frequency applies to every entity or system.

3. Application, API, Mobile, Cloud, and Supplier Security

Healthcare portals, clinician applications, mobile apps, APIs, integrations, and cloud platforms should be included in the control environment from design through retirement. Security requirements belong in architecture, procurement, development, change management, testing, deployment, monitoring, and supplier oversight. Contractual controls should address data handling, access, incident notification, subcontractors, evidence, audit rights, and termination. Confirm any data-location or cross-border restriction from current official sources rather than historical summaries. Related DeepStrike resources include web application penetration testing, mobile application penetration testing, and the distinction between vulnerability assessment and penetration testing.

Evidence: architecture reviews, secure SDLC records, change approvals, application and API test results, cloud inventory, shared-responsibility matrix, supplier assessments, contractual clauses, exit plans.
Practical test: confirm that the systems carrying the highest-risk health information are present in the asset, logging, vulnerability-management, and recovery scopes.
Do not assume that an ISO 27001 certificate or SOC 2 report removes the need to assess service-specific risk.

4. Logging, Incident Response, Continuity, and Recovery

Logging and monitoring should support detection, investigation, access review, and evidence preservation. Incident response should define roles, escalation, legal and privacy coordination, communication, evidence handling, supplier involvement, and regulator notification where applicable. Because reporting thresholds and deadlines can be legally significant, confirm them from the current official DoH and legal sources. Continuity planning should prioritize clinical service, patient safety, data availability, supplier dependencies, backups, recovery testing, and workable manual procedures.

Evidence: logging standards, retention settings, alert reviews, incident plans, completed exercises, communication records, backup and restoration tests, recovery reports, lessons learned.
Practical test: choose a material incident scenario and verify the end-to-end flow from detection through escalation, containment, legal analysis, notification decision, recovery, and management review.
Confirm the applicable reporting threshold, recipient, and deadline from current DoH and legal sources; do not assume a universal notification period.

5. Workforce, Physical Security, and Privacy

Healthcare security also depends on personnel and physical controls. Define background-screening requirements where lawful and applicable, role-based awareness, acceptable use, confidentiality, onboarding and termination, visitor controls, secure areas, device protection, media handling, and disposal. Use “health information” or “patient health information” in the UAE context. Reserve “PHI” for explicit comparison with HIPAA because it is a US legal term.

Evidence: training completion, role-specific training, acknowledgements, visitor logs, access records, secure-disposal records, privacy assessments, processing and retention records.
Privacy and cybersecurity overlap but are not interchangeable. ADHICS should not be presented as a replacement for the UAE PDPL or other applicable privacy requirements.
Legal interpretation of lawful basis, rights, exemptions, international transfers, and notification obligations requires qualified legal review.

Does ADHICS Require Penetration Testing?

ADHICS V2 includes vulnerability assessment and penetration-testing requirements for applicable entities and systems. The precise scope, frequency, independence condition, and system categories depend on the current official control text and the organization’s applicability category. Vulnerability assessment and penetration testing remain distinct activities; see DeepStrike’s comparison of vulnerability assessment and penetration testing for planning context. Testing is one part of compliance evidence, not proof of overall ADHICS compliance.

Question	Answer	Important Caveat
Is penetration testing explicitly named?	Yes. ADHICS V2 includes penetration testing for applicable entities and systems.	Confirm the current control text and applicability conditions.
Is vulnerability assessment also required?	Yes. Vulnerability assessment and penetration testing are addressed as distinct assurance activities.	Do not treat scanning and penetration testing as equivalent.
Is there an annual frequency?	ADHICS V2 describes a yearly testing schedule for the applicable control scope.	Confirm whether the requirement applies to the entity category and systems in question.
Are web, mobile, infrastructure, and connected devices included?	The V2 control scope includes multiple technical environments and specified connected systems.	Use the exact official scope; add APIs or cloud only when supported by the control or approved risk scope.
Must the tester be independent?	The control refers to independent internal or external assessment.	Confirm the current definition, competence, and any assessor conditions.
Is retesting required?	Findings should be remediated and revalidated.	Define the retest scope, environment, version, evidence, and limitations.
Does a clean report prove compliance?	No.	A test covers selected assets and attack paths at a point in time; governance and other controls remain outside scope.

How Penetration Testing Can Support ADHICS Readiness

Authorized testing can provide evidence that selected technical controls work under realistic conditions. It can identify vulnerabilities that scanning, configuration review, or documentation alone may miss. Its value is highest when the scope follows the organization’s asset and data-flow inventory, the rules of engagement protect clinical operations, findings are mapped to owners, and remediation is retested. NIST SP 800-115 provides general assessment-planning guidance, while the OWASP Web Security Testing Guide, OWASP API Security Project, and OWASP MASVS provide technical references for web, API, and mobile testing. These sources support implementation; they do not establish ADHICS compliance.

Security Area	What Testing Can Assess	Useful Evidence	What It Does Not Prove
External exposure and network perimeter	Identify exposed services, unsafe configurations, segmentation weaknesses, and reachable attack paths.	Report with affected assets, evidence, impact, and approved remediation.	It does not prove every network rule or internal segment is secure.
Web applications and patient portals	Assess authentication, authorization, session handling, input validation, business logic, and sensitive-data exposure.	Application test report linked to the tested version and scope.	It does not prove all code paths or future releases are secure.
APIs and integrations	Assess object-level authorization, authentication, workflow, rate handling, and data exposure.	API inventory, tested endpoints, findings, and remediation records.	Unknown or undocumented APIs may remain outside scope.
Mobile applications	Assess application storage, transport, platform use, backend interaction, and authorization.	Mobile and backend findings with build/version details.	The mobile client test alone does not cover all server-side risk.
Cloud environment	Assess agreed IAM, exposure, storage, network, secrets, and attack-path conditions within provider policy.	Cloud assessment evidence and shared-responsibility scope.	It does not replace full configuration governance or provider assurance.
Identity and privileged access	Test selected authorization boundaries, MFA workflows, privilege paths, and account controls.	Approved test accounts, findings, and access-control remediation.	It does not prove every workforce account is correctly governed.
Logging and detection	Confirm whether selected test events produce useful logs and alerts.	Event records, detection tickets, and lessons learned.	A limited test does not prove complete monitoring coverage.
Remediation validation	Retest specific corrected vulnerabilities.	Retest status and residual-risk record.	Closure applies only to the specific issue and tested condition.

Healthcare-Safe Penetration-Testing Scope

Healthcare testing must protect clinical continuity and patient safety. Written authorization should identify every asset owner, third-party approval, test environment, data-handling rule, excluded action, timing constraint, escalation route, and emergency-stop condition. Use synthetic or dedicated test data where possible. Destructive testing, denial-of-service activity, testing of life-critical devices, or access to real patient records should be excluded unless a separately approved and clinically safe plan exists.

Scope Area	Questions to Resolve	Healthcare-Safety Constraint
Patient and clinician portals	Authentication, authorization, session, workflow, and data exposure.	Use test accounts; avoid real records and live-care disruption.
APIs and integrations	Document endpoints, trust boundaries, owners, and data exchanged.	Obtain permission from each system owner; respect rate and availability limits.
Mobile health applications	Test the approved build, backend, storage, transport, and permissions.	Prefer test environments and synthetic data.
Cloud services	Define accounts, subscriptions, regions, services, identities, and provider permissions.	Follow provider testing policy and avoid cross-tenant activity.
External and internal networks	Define IP ranges, segments, VPNs, remote access, and approved pivots.	Exclude denial-of-service; coordinate maintenance and clinical windows.
Identity systems	Define test users, roles, MFA, SSO, privileged paths, and lockout protections.	Prevent production lockouts; maintain rapid recovery contacts.
Medical and connected devices	Identify ownership, clinical function, vendor constraints, and approved checks.	No invasive or availability-impacting test without explicit clinical and vendor approval.
Third-party systems	List integrations and responsibilities.	Do not test a supplier asset without direct written authorization.
Logging and detection	Agree which events the SOC should detect and whether the test is disclosed.	Use safe test cases; preserve evidence without exposing sensitive data.
Emergency controls	Name technical, clinical, vendor, and executive contacts.	Define stop conditions, rollback, incident response, and communication.

Remediation, Retesting, and Assurance

Testing creates value only when findings move through a controlled remediation process. Assign an owner and target date, verify root cause, document compensating controls, preserve evidence, assess residual risk, and obtain formal approval for exceptions. A retest should state exactly what was retested, against which environment and version, and whether the original condition is no longer reproducible. It should not imply that the entire system is secure.

Stage	Required Action	Evidence
Triage	Validate the finding, affected asset, business impact, clinical relevance, and ownership.	Triage record; risk rating; owner.
Remediation plan	Define corrective action, dependency, deadline, and acceptance criteria.	Ticket; plan; change record.
Exception or compensating control	Document why the issue cannot be fixed and what reduces the risk.	Risk acceptance; approval; review date.
Retest	Reassess the specific finding after the change.	Retest evidence; status; limitations.
Residual-risk review	Assess what remains after remediation and whether broader control changes are needed.	Updated risk register; management decision.
Trend and governance reporting	Track recurring weakness, overdue items, and control themes.	Dashboard; committee minutes; improvement plan.

ADHICS Compared With Related Frameworks

Comparisons help readers understand scope, but they can create false equivalence. Use the table below as orientation rather than legal interpretation, and confirm the current legal and standards context when applying it. For US-specific testing context, see DeepStrike’s HIPAA penetration testing guide.

Framework	Primary Scope	Geographic/Sector Focus	Relationship to ADHICS	Important Caveat
ADHICS	Healthcare information and cybersecurity controls	Abu Dhabi healthcare	Primary framework discussed in this guide.	Confirm current scope, version, and authority process.
ISO/IEC 27001	Information security management system	Global, cross-sector	Can provide a governance and control baseline.	Certification does not automatically establish ADHICS compliance.
UAE PDPL	Personal-data protection law	UAE, subject to scope and exemptions	May apply alongside healthcare security requirements.	Cybersecurity controls do not replace legal privacy analysis.
HIPAA	US healthcare privacy and security law	United States	Useful only for high-level conceptual comparison.	HIPAA terminology and legal scope do not govern Abu Dhabi by default.
Dubai healthcare requirements	Healthcare regulation and security requirements	Dubai	Separate local authority context.	Do not merge Dubai and Abu Dhabi obligations.
NIST CSF and NIST publications	Voluntary cybersecurity guidance	Global use	Useful for implementation, assessment, and testing structure.	Not a substitute for ADHICS.
OWASP guidance	Application, API, and mobile security guidance	Global use	Supports technical testing and secure-development practices.	Does not establish regulatory compliance.
PCI DSS	Payment-card data security	Cardholder-data environments	May apply to payment systems within a healthcare organization.	It covers a narrower data and system scope.

Common ADHICS Readiness Gaps

The following are illustrative programme gaps, not claims about the most common audit findings in Abu Dhabi. Use them as a review aid and map each one to the current official controls.

Illustrative Gap	Why It Matters	Evidence of Improvement
Unclear applicability or outdated standard	Teams may implement the wrong scope or control version.	Approved applicability memo and current control matrix.
Incomplete asset and data-flow inventory	Systems, APIs, cloud services, devices, or suppliers can remain outside control coverage.	Reconciled inventory, diagrams, ownership, and review records.
Policies without operating evidence	Documentation exists, but there is no proof the process is used.	Logs, tickets, approvals, reviews, and sample evidence.
Undefined control ownership	Gaps remain unresolved because no accountable owner exists.	Named owners, RACI, escalation, and management review.
Weak privileged and third-party access governance	High-impact access may be overbroad or remain active.	Access reviews, MFA, approvals, time limits, and revocation records.
Testing scope excludes APIs, cloud, identity, or integrations	Important attack paths remain unassessed.	Risk-based scope linked to asset and data-flow inventory.
Findings are not tracked to closure	The organization cannot show that risk was reduced.	Remediation tickets, exceptions, retests, residual-risk decisions.
Incident and recovery plans are untested	Plans may fail during a real disruption.	Exercises, restoration tests, lessons learned, updated plans.
Supplier assurance relies on certificates alone	A certificate may not address the actual service and data flow.	Service-specific risk review, contracts, evidence, and monitoring.
ISO 27001 or one penetration test is treated as complete compliance	Related assurance is mistaken for full ADHICS coverage.	ADHICS-specific gap analysis and multi-layer evidence model.

ADHICS Compliance Readiness Checklist

Readiness Item	Owner	Evidence	Status
Current version and applicability confirmed	Compliance/legal	Official documents, applicability memo	Needs verification
Control ownership approved	Executive/CISO	RACI, committee minutes	Not assessed
Risk assessment and treatment plan current	Risk/CISO	Risk register, treatment plan	Not assessed
Asset inventory and data flows complete	IT/data owners	CMDB, diagrams, ownership records	Not assessed
Access and privileged access reviewed	IAM/IT security	Review records, MFA evidence	Not assessed
Infrastructure and endpoint controls evidenced	IT operations	Patch, configuration, EDR, segmentation evidence	Not assessed
Application, API, mobile, and cloud scope defined	Engineering/cloud/AppSec	Inventory, architecture, test records	Not assessed
Logging and incident response validated	SOC/IR	Logs, alerts, plan, exercises	Not assessed
Continuity and recovery tested	BCM/IT/clinical operations	Restore tests, exercises, lessons learned	Not assessed
Suppliers and third-party access reviewed	Procurement/GRC	Assessments, contracts, access records	Not assessed
Workforce and physical controls evidenced	HR/facilities/security	Training and access records	Not assessed
Vulnerability management and testing programme current	Security/system owners	Schedules, reports, tickets	Not assessed
Remediation and retesting tracked	Security/engineering	Tickets, exceptions, retest records	Not assessed
Management review completed	Executive/board committee	Management pack, minutes, approvals	Not assessed

Checklist limitation
This is an editorial readiness checklist, not an official audit instrument. Replace or map each item to the current applicable ADHICS control before assessment.

How to Select an ADHICS Security-Testing Provider

Select a provider based on healthcare-safe delivery, technical relevance, evidence quality, and scope discipline not on a claim that the provider can guarantee compliance. Confirm the exact services, personnel, certifications, insurance, data-handling practices, and retesting terms during procurement.

Buyer Criterion	What Good Looks Like
Authorization and scope	Requires written authorization, asset ownership, third-party permission, rules of engagement, and stop conditions.
Healthcare safety	Plans around clinical operations, patient safety, production risk, test accounts, synthetic data, and emergency response.
Relevant technical capability	Matches the actual scope: web, API, mobile, cloud, network, identity, or connected technology as applicable.
Evidence handling	Protects reports, screenshots, credentials, logs, and any sensitive data; defines retention and deletion.
Report quality	Explains risk, affected assets, evidence, business impact, remediation, scope limitations, and executive priorities.
Remediation and retesting	Defines what retesting includes, timing, exclusions, and how residual risk is reported.
Compliance restraint	Maps evidence to relevant controls without claiming certification, regulatory approval, or guaranteed audit success.
Independence and conflicts	Discloses conflicts and meets any independence requirement that applies to the assessment.

DeepStrike
DeepStrike can support authorized penetration testing for agreed web, API, mobile, cloud, network, and identity scope where those services are confirmed for the engagement. Testing can provide evidence about selected technical controls, but ADHICS applicability, compliance conclusions, legal interpretation, and regulatory acceptance remain the organization’s responsibility.

Frequently Asked Questions

What is ADHICS compliance?

It is the process of meeting the applicable governance, security, operational, evidence, and review requirements of the Abu Dhabi Healthcare Information and Cyber Security Standard. Applicability and the current version should be confirmed from official Department of Health sources.

What does ADHICS stand for?

ADHICS stands for Abu Dhabi Healthcare Information and Cyber Security Standard.

Is ADHICS mandatory across the UAE?

It should not be described as a single UAE-wide rule. It is associated with the Abu Dhabi healthcare sector. Organizations operating in other emirates should identify the relevant local authority and federal laws.

Who needs to comply with ADHICS?

The answer depends on the current official applicability rules, the organization’s Abu Dhabi healthcare licence, role, systems, data-processing responsibilities, and contracts. Suppliers may also receive contractual control obligations.

What is the current ADHICS version?

This guide addresses ADHICS V2. Because standards and circulars can be amended, confirm the current official document, effective date, and any later update before relying on version-specific requirements.

What are the main ADHICS requirements?

The framework covers governance, risk, assets, access, infrastructure, applications, cloud and suppliers, monitoring, vulnerability management, incident response, continuity, workforce, physical security, and health-information protection.

Does ADHICS require penetration testing?

ADHICS V2 includes vulnerability assessment and penetration testing for applicable entities and systems. The exact scope, frequency, independence conditions, and covered technologies depend on the current control text and the organization’s applicability category. A test remains one part of the wider compliance evidence set.

How can penetration testing support ADHICS readiness?

It can identify technical weaknesses, validate selected controls, test realistic attack paths, and provide remediation evidence. It cannot assess every governance, privacy, workforce, physical, or continuity requirement.

Is ISO 27001 certification enough for ADHICS?

No automatic equivalence should be claimed. ISO 27001 can provide a strong information-security management baseline, but an ADHICS-specific applicability and gap review is still needed.

How is ADHICS different from HIPAA?

HIPAA is a US legal framework. ADHICS is associated with Abu Dhabi healthcare security. Their terminology, jurisdiction, regulated entities, and legal obligations differ.

What evidence is needed for an assessment?

Typical evidence includes policies, ownership records, risk assessments, inventories, configurations, access reviews, logs, supplier records, training, incident and recovery records, security assessments, remediation tickets, retests, and management decisions.

Does a clean penetration-test report prove compliance?

No. It shows the result of a defined technical test at a point in time. Compliance requires a much broader set of controls and evidence.

Conclusion

ADHICS compliance should be approached as an ongoing healthcare security and assurance programme, not a one-time document exercise. Start by confirming the current official version and applicability. Define the organization, sites, systems, health-information flows, suppliers, and assessment boundaries. Then map controls to owners and operating evidence, validate selected technical safeguards, remediate weaknesses, retest where appropriate, and report residual risk to accountable management.

Penetration testing can be an important part of this process when the official control framework or the organization’s risk profile calls for it. Its role is to provide evidence about selected attack paths and technical control effectiveness. It does not replace governance, privacy analysis, incident readiness, continuity, supplier oversight, workforce controls, or regulatory review. A healthcare-safe scope, written authorization, patient-safety constraints, secure evidence handling, and disciplined remediation are essential.

About the Author

Mohammed Khalil, CISSP, OSCP, OSWE, is a Cybersecurity Architect at DeepStrike specializing in penetration testing, application security, cloud security, API security, identity exposure, offensive security operations, and technical security assurance. His work focuses on identifying practical attack paths, improving remediation decisions, and helping organizations connect technical testing with broader governance and compliance objectives.

ADHICS Compliance in the UAE: Abu Dhabi Healthcare Security Requirements