An ADHICS audit can become uncomfortable long before an auditor finds a missing policy. The difficult questions usually start with evidence. Was every system handling health information covered by testing? Did the scope include APIs, internet-facing applications, cloud services and connected medical devices? If weaknesses were found, can your team show they were fixed and checked again?
Those questions matter even more in 2026. In May 2026, the UAE Cyber Security Council reported that more than 800,000 cyberattacks a day had been recorded in recent months. For Abu Dhabi healthcare organisations, a penetration test cannot be treated as an annual report that simply sits in a folder.
For organisations to which CO 7.1 applies, ADHICS V2 requires scheduled vulnerability assessment and penetration testing, with findings followed through remediation and revalidation. This blog explains what that means before your next ADHICS audit, what needs to be tested, what evidence to keep and where problems often appear.
What Is an ADHICS Audit?
ADHICS and the Department of Health (DoH)
ADHICS, the Abu Dhabi Healthcare Information and Cyber Security Standard, sets information security and cybersecurity requirements for organisations handling health information within Abu Dhabi’s healthcare sector. Version 2 was published in May 2024 and became effective in August 2024.
The Department of Health – Abu Dhabi oversees the standard through its AAMEN programme. DoH uses AAMEN to assess healthcare facilities against its information security requirements. ADHICS V2 also states that the health-facility audit programme integrates external compliance audits and links them with facility licensing, including new registrations and renewals. For organisations working towards ADHICS certification, this makes audit readiness an ongoing process rather than something to prepare for only at renewal time.
An ADHICS audit, therefore, is not only a check of written policies. Teams also need records showing that required security work has been carried out.
ADHICS V2 also requires every entity to maintain its own annual audit programme. Organizations should conduct these independent audits at least annually, or after a major change, using internal or external resources that are independent from the work being reviewed.
What Auditors Look For
On the governance side, this can include the organization taking on information security responsibilities, conducting risk assessments, maintaining the risk register, developing policies, performing internal audits, and keeping records showing how they follow corrective actions.
For technical security, the questions move towards the systems themselves. What did the team test? When did they test it? What did they find? Did they fix the weaknesses and check them again?
This is where penetration testing records become important. Before a DoH Abu Dhabi compliance audit, the organisation should be able to show which systems were tested, what was found and what happened after weaknesses were reported.
Is Penetration Testing Required for ADHICS Compliance?
CO 7.1 is an Advanced control and also applies to Healthcare Technology and Service Providers. Its applicability depends on the organisation’s ADHICS control category and risk profile.
Whether CO 7.1 applies should also be checked against the organisation’s Statement of Applicability. ADHICS requires the SoA to record the controls considered necessary, their implementation status and the reason for excluding any risk-based applicable control.
Where CO 7.1 applies, the organisation must establish a yearly vulnerability assessment and penetration testing schedule. The requirement covers systems, networks and infrastructure, internet-accessible web and mobile applications, and connected medical devices.
ADHICS V2 also requires security testing for new deployments and system changes before they go into production. Findings cannot simply remain in the report. They need remediation timelines, follow-up and revalidation to check whether the fixes worked.
Organizations may carry out the independent technical assessment internally or externally. ADHICS V2 does not require that a third-party provider perform every penetration test.
Independence matters whether the assessment is internal or external. In practical terms, the people testing the controls should be sufficiently separate from the people responsible for building or operating them, so the assessment is not simply a review of their own work.
Why Vulnerability Scanning Isn’t Sufficient
A vulnerability scan is useful, but it does not satisfy the penetration-testing part of CO 7.1.
A scanner can check many systems for known weaknesses, missing patches, outdated software and common configuration problems. This makes scanning useful for ongoing vulnerability management. It cannot always tell you whether an attacker can actually use a weakness against your systems or what access they could gain from it.
A finding that looks minor on its own may become more serious when combined with weak access controls, an exposed API or another weakness elsewhere.
The ADHICS V2 Implementation Guideline says penetration testing should follow vulnerability assessment to confirm the actual risk. It also describes penetration testing as using automated and manual methods to exploit vulnerabilities.
For an ADHICS audit, scanner output shows only part of what happened. The organisation should also be able to show what it tested, what it found, what it fixed and whether it checked those fixes again.
Which Healthcare Systems Should We Test?
ADHICS tells you the main areas that need testing. The harder part is making sure nothing is missed when the scope is set.
Following the movement of health information through your systems is a useful starting point.
Healthcare Applications
This may include:
- Patient portals and mobile apps
- Clinical and administrative applications
- Telehealth platforms
- Systems used to view, enter or manage health information
APIs and System Connections
Do not look only at the application a patient or clinician sees. The connections behind it can matter just as much. These may include FHIR or HL7 interfaces, APIs connecting laboratories and pharmacies, insurance systems, EMRs and third-party healthcare platforms.
An organisation might test its patient portal but miss the API carrying data between that portal and the laboratory system. That leaves part of the same service outside the test.
Cloud and Network Infrastructure
You should also consider cloud-hosted applications, storage, identity systems, network controls and backup environments when you prepare the scope.
ADHICS V2 has specific requirements for cloud security.
Where organizations use cloud services, the standard requires an independent external party to test the service design, service components, and implemented security controls.
Network separation also matters, particularly when organizations keep clinical, corporate, and medical-device networks apart.
Connected Medical Devices
ADHICS V2 includes connected medical devices in the yearly testing requirement. Depending on the facility, these could include connected patient monitors, infusion pumps, diagnostic equipment, remote-patient-monitoring technology and the systems used to manage them.
Clinical engineering teams should not cause people to miss these devices simply because they manage them rather than IT.
Internal Systems
Internal infrastructure may provide a route to health information or other critical systems. This can include authentication services, databases, file servers, virtual systems and internal networks.
Before finalising the test scope, compare it with the asset inventory and data flows. Check which systems store, process, or transmit health information, what they connect to, and whether you have missed cloud services or connected medical devices.
The aim is not to produce the longest possible list. It is to avoid leaving systems out simply because they sit behind another application or are owned by a different team.
What Should ADHICS Penetration Testing Cover?
Once the systems are in scope, the next question is what testers should look for. The focus should be on ways someone could gain access, move between systems or reach health information they should not be able to see.
Authentication and Access Control
Start with how users get into the system and what they can do once they are inside.
Testing may check whether attackers can bypass authentication, take over sessions, or reach functions meant for administrators or other roles as a normal user.
For a patient portal, one useful test is whether one patient can change an account or record reference and view another patient’s information. For clinical systems, testers may check whether users can reach records or functions outside their assigned permissions.
ADHICS V2 also sets requirements around privileged and remote access. Remote access, for example, is expected to use two-factor authentication.
Patient Data and Application Security
Testers should look for places where the application itself could expose health information.
Weak access controls, insecure session handling, injection flaws, information that error messages expose, and sensitive data that is returned when it is not needed can include this.
Check where encryption forms part of the system being tested.
ADHICS V2 covers protection of data at rest and in transit, along with requirements for encryption keys, including in cloud environments.
Simply seeing encryption enabled does not tell the full story. Testing should check whether there are still ways to reach the data without the expected protection.
APIs and System Connections
APIs deserve separate attention because healthcare applications rarely work alone. Patient portals, laboratory systems, pharmacies, insurers and other platforms may exchange information through APIs or healthcare interfaces.
Testing should check whether the API verifies who is making a request and whether that user is allowed to access the requested record or function. It can also check for unnecessary data in responses, weak token handling, older endpoints that are still accessible and unsafe input handling.
OWASP lists broken object-level authorisation and broken authentication among its API Security Top 10 risks. In a healthcare system, an authorisation flaw could allow someone to change an ID in a request and reach another patient’s record.
Infrastructure and Cloud
Infrastructure testing may cover exposed services, insecure configurations, weak administrative access and whether network controls stop an attacker from moving into other parts of the environment.
ADHICS V2 requires medical-device and remote-patient-monitoring networks to be separated from the corporate network, with traffic between network zones controlled. Testing can check whether that separation works as intended.
Cloud testing may also look at storage permissions, administrative access, exposed services and configuration weaknesses.
Connected Medical Devices and Vendor Access
Connected medical devices should not be tested in exactly the same way as ordinary office systems.
Testing may look at device access controls, network exposure, connections with other systems and whether a weakness elsewhere could provide a route into the medical-device network.
ADHICS V2 limits medical-device access to authorised users and includes connected medical devices in its technical testing requirements.
Vendor access also needs attention, especially where a supplier can remotely reach medical devices or supporting systems.
Testing on equipment involved in patient care needs extra care. For teams comparing medtech security testing UAE providers, experience with live clinical environments and connected devices matters more than generic infrastructure testing alone. A technique that is safe against a test web application may not be safe against a live medical device.
Before testing begins, we should agree on the scope, timing, and testing limits.
For live clinical equipment, the rules of engagement should also specify when we must stop testing if the device behaves unexpectedly or if patient-care operations could be affected.
How Penetration Testing Supports an ADHICS Audit
Showing Whether Security Controls Hold Up
A policy may say that access is restricted by user role. Penetration testing can check what happens when a normal user tries to reach records, functions or administrator areas they should not be able to access.
The same applies to other technical controls. Testing can show whether authentication can be bypassed, whether network separation stops movement between systems, or whether protected information becomes exposed through an application or API.
This gives the organisation more than a written control. It gives evidence of how that control behaved during testing.
Following Findings Through to Revalidation
ADHICS V2 requires organisations to manage findings, set remediation timelines and follow up on their status with the people responsible for the fixes.
Closing a ticket is not the same as checking the vulnerability again.
CO 7.1 requires the effectiveness of mitigation measures to be verified through revalidation. If a finding has been fixed, the organisation should be able to show that the correction was checked rather than relying only on a completion note.
ADHICS Penetration Testing Checklist
A useful checklist should cover more than the test itself. Scope decisions, testing records, remediation and revalidation may all become part of the evidence later.
Before Testing
Start by checking what needs to be included.
- Compare the proposed scope with the asset inventory
- Follow how health information moves between applications, APIs and supporting systems
- Include connected medical devices and internet-facing web and mobile applications where applicable
- Check whether cloud services and internal infrastructure have been considered
- Record anything left outside the test and why
For new deployments or changes, ADHICS V2 specifically requires security testing and authorisation from the authorised business and security stakeholders before production use.
The testing team should also agree the rules of engagement before work begins. That normally includes what testers can test, techniques they should not use, testing times, emergency contacts and what happens if they find a serious issue.
During Testing
The tester should stay within the agreed scope and keep a clear record of what was tested.
Useful records can include:
- Systems and applications tested
- Testing dates
- Methods used
- Findings and affected assets
- Evidence supporting each finding
- Severity or risk rating
- What an attacker could do if the weakness were used
OWASP guidance can help with web and API testing, but ADHICS V2 does not require one specific penetration-testing methodology.
Keep access to what is necessary and protect the information throughout the engagement where health information could be exposed during testing.
Report serious findings to the security team during testing rather than holding them until the final report. Agree on the escalation process before testing begins.
After the Test
A report is only the start of the follow-up work.
CO 7.1 requires organisations to manage findings, define remediation timelines and follow up with the people responsible for the fixes. ADHICS does not give a universal 30, 60 or 90-day timetable, so deadlines should be set according to the finding, risk and the organisation’s own vulnerability-management process.
For each finding, keep enough information to answer simple questions later:
- Who owns the fix?
- What did they change?
- When did they complete it?
- Did they leave anything unresolved?
- Did they check the correction again?
If a vulnerability cannot be fixed immediately, the ADHICS V2 Implementation Guideline allows organizations to implement compensating controls, meaning they can use other safeguards to reduce the risk until they fix the issue.
Revalidation
Closing a remediation ticket does not show that the weakness has disappeared.
ADHICS V2 requires organisations to verify mitigation through revalidation. Its Implementation Guideline specifically calls for a revalidation scan after the solution for a high-risk vulnerability has been applied.
Keep the revalidation result with the original finding and remediation records.
Before the ADHICS Audit
Bring the testing records together before someone asks for them.
Depending on the assessment, this may include:
- Documented test scope
- Rules of engagement
- Penetration testing report
- Records showing who owned each finding
- Remediation evidence
- Revalidation results
- Records for unresolved findings and any compensating controls used
Someone from the security team should also be able to explain why the scope was chosen, what the important findings meant and what happened after they were reported.
The paperwork matters, but the team should understand the story behind it too.
Choosing a Healthcare Penetration Testing Provider
ADHICS V2 does not require every penetration test to be carried out by a third party. When choosing a healthcare penetration testing vendor, look for a team that understands clinical systems, APIs, cloud environments and connected devices, not only standard web application testing.
Healthcare and ADHICS Experience
Ask whether the provider has worked with healthcare environments and understands the systems likely to fall within an ADHICS assessment.
Useful experience can include:
- ADHICS or Abu Dhabi healthcare security work
- Clinical applications, APIs and healthcare integrations
- Connected medical devices and IoMT
- Cloud and internal infrastructure used by healthcare organisations
A technically capable tester may still struggle if they do not understand how clinical systems connect or why testing a live medical device needs different safety limits from testing a normal web application.
Testing Capability
Look at the people who will actually perform the assessment, not only the company profile.
The team should be comfortable with manual testing, APIs, cloud infrastructure and internal networks where these fall within scope.
If you include connected medical devices, ask who has experience testing them and how the engagement will protect patient-care systems.
Certifications such as OSCP or GPEN are useful, but having hands-on experience with the systems you test matters just as much.
Handling Health Information
Testing can expose health information, credentials, screenshots, logs or other sensitive material.
Before work starts, you should agree who can access test data, how you will store and transfer it, how long you will keep it and how you will remove it afterwards.
The provider should agree these data-handling rules with your team before testing starts.
Where CO 7.2 applies, ADHICS also requires that the engaged party remove assessment information from the third party’s environment and protect shared reports. This is worth checking before a provider hands over test data or reports.
Reporting and Revalidation
The report needs to be useful after the test is over.
Findings should clearly identify the affected system, describe what you found, explain why it matters, and provide enough technical evidence for the internal team to understand the issue. Remediation guidance should tell the team what needs to change without relying on vague statements such as “improve security controls.”
Check whether revalidation is included or available after remediation.
For leadership, a shorter summary can explain the more serious findings and their impact. Technical teams will need the detail behind them.
Common Penetration Testing Mistakes Before ADHICS Audit
Some problems appear before testing even starts. Others only become obvious when the organisation tries to explain what was tested and what happened afterwards.
Testing Too Narrow a Scope
A patient portal may be the most visible system, but it can connect to APIs, laboratory systems, identity services, cloud infrastructure and other clinical platforms. Compare the planned scope with the asset inventory and data flows, and document what you included and why you left anything out.
Closing Findings Without Revalidation
A remediation ticket may say “fixed”, but we require the effectiveness of mitigation measures to be checked through revalidation.
If someone reported a weakness, keep the finding, the remediation record, and the result of the follow-up check together. That makes it much easier to show that we did not simply mark the issue complete and forget about it.
Losing the Evidence After Testing
Testers may have done testing correctly and it may still become difficult to explain months later if the records are scattered.
Keep the scope, report, remediation records and revalidation results somewhere the security team can retrieve them without searching across old email threads or individual laptops.
Management requires CO 7.1 findings and mitigation status to be reported, defines remediation timelines, and continues follow-up with the people responsible for the fixes.. Therefore, you should treat those records as part of the testing process, not as paperwork to organise just before the audit.
Poor Coordination Before Testing
Clear ownership and agreed boundaries are essential when conducting penetration testing in a healthcare environment, especially with clinical systems or medical devices involved.
For new deployments and changes, ADHICS V2 requires security testing and authorisation from authorised business and security stakeholders before production use. For other testing, the organisation should still make sure the people responsible for the affected systems know the testing boundaries, timing and escalation process.
How Qualysec Helps with ADHICS Audit Preparation
Preparing for an ADHICS audit can become difficult when different teams split the testing or when reports contain findings with no clear follow-up.
Qualysec can support VAPT for healthcare platforms, including applications, APIs, cloud environments, networks and connected devices. That helps healthcare teams check the patient-facing systems they already know about, as well as the infrastructure and connections behind them.
The team also has healthcare testing experience. In one recent healthtech engagement, Qualysec assessed three public-facing websites and network infrastructure and found 29 vulnerabilities, including two high-severity issues.
After testing, Qualysec provides remediation guidance, while users can use its Vulnerability Dashboard to track findings, assign fixes, request retests, and keep testing records together.
Preparing for an ADHICS audit? Qualysec can help test the systems in scope and support your team through remediation and retesting before the DoH review.
Conclusion
Passing an ADHICS audit is not only about having policies in place. Your team also needs to show that they have carried out the required security work, followed up on weaknesses, and checked the fixes.
Where CO 7.1 applies, that means setting a clear scope, completing the yearly vulnerability assessment and penetration testing, keeping the findings and remediation records, and checking fixes through revalidation. ADHICS allows teams to perform the independent technical assessment internally or externally.
The useful question before an audit is simple: if someone asks what your team tested, what your team found, and what happened next, can your team answer without searching through old reports and emails?
Frequently Asked Questions
1. What is an ADHICS audit?
An ADHICS audit checks whether a healthcare organisation meets the Abu Dhabi Department of Health’s information security requirements. It looks at governance, security controls and the records used to show those controls have been put in place.
2. Does ADHICS require penetration testing?
Yes, where CO 7.1 applies. CO 7.1 is an Advanced control and also applies to Healthcare Technology and Service Providers. It requires a yearly vulnerability assessment and penetration testing schedule across the systems, networks, internet-facing applications and connected medical devices listed in the control.
3. What systems should be tested before an ADHICS audit?
The scope should include the systems, networks and infrastructure covered by CO 7.1, including internet-facing web and mobile applications and connected medical devices. Asset inventories and health-information flows can help find systems or connections that might otherwise be missed.
4. How often should penetration testing be conducted?
Where CO 7.1 applies, ADHICS V2 requires a yearly vulnerability assessment and penetration testing schedule. New deployments and changes must also undergo security testing before production use. The standard does not prescribe quarterly or semi-annual penetration testing.
5. Is penetration testing different from vulnerability scanning?
Yes. Vulnerability scanning finds possible weaknesses across systems. Penetration testing goes further by checking whether weaknesses can actually be used and what risk they create. The ADHICS V2 Implementation Guideline says penetration testing should follow vulnerability assessment to confirm actual risk.
6. What if we do not have penetration testing evidence before an ADHICS audit?
If CO 7.1 applies to the organisation and the required testing has not been completed, it may not be able to show compliance with that control. The exact audit outcome will depend on the assessment, so it is safer not to claim that a specific finding, re-audit or penalty will automatically follow.
