ASD ISM 1782 Use protective DNS to block malicious domains
What it says
A protective DNS service is used to block access to known malicious domain names.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishA service that prevents access to harmful website addresses.
A protective DNS service acts as a filter for internet connections by blocking access to known harmful websites. This matters because if you're not blocking these bad sites, you risk exposing your systems to viruses, data theft, or disruptions that can damage your business or organisation.
Free. Save your status, tasks and notes.
Why it matters
Without protective DNS filtering, users may resolve and connect to known malicious domains, increasing malware infection and credential theft risk.
How to implement
IT team should set up a protective DNS service: Choose a DNS provider that offers security filtering, such as blocking malicious websites.
The team needs to configure network settings to route all internet traffic through this secure DNS to ensure any harmful sites are intercepted.
Managers should mandate DNS protection in IT policies: Update organisational policies to require all internet traffic to use the protective DNS service.
Clearly communicate this policy to all staff and ensure everyone understands the importance of not bypassing it.
System administrators should regularly update DNS filtering lists: Check for updates from the DNS provider and apply them to your network.
This ensures that the DNS service is equipped with the latest information on new threats and blocked sites.
Procurement should evaluate DNS service options: When acquiring a DNS service, assess each vendor's security features and support capabilities.
Choose a provider that offers robust protection and regular threat intelligence updates.
Training coordinators should educate staff on DNS protections: Organise informational sessions for employees explaining the purpose of the protective DNS and how it safeguards their work.
Use examples of what could happen without these protections to reinforce the message.
Keep it running
Ensure the protective DNS service ingests current threat intel feeds and review allow/block exceptions regularly to prevent bypass and false positives.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The DNS service agreement: Request to see the contract or agreement with the DNS provider.
Look at
Clauses that specify security features such as threat intelligence and blocking capabilities.
Good evidence
Includes documented terms of service clearly mentioning protection against malicious domains.
- Check 2 of 5What an auditor asks for
Ask for
The network configuration settings: Request a demonstration or a document showing how internet traffic is routed through the protective DNS.
Look at
DNS server addresses set to the secure DNS provider.
Good evidence
Is a configuration showing no bypasses and using only authorised DNS settings.
- Check 3 of 5What an auditor asks for
Ask for
The DNS filtering update logs: Request records or logs showing when and how the DNS filtering lists are updated.
Look at
The frequency of updates and whether the latest threats are included.
Good evidence
Includes a regular update schedule with evidence of the most recent updates.
- Check 4 of 5What an auditor asks for
Ask for
Policy documents: Request documentation that mandates the use of the protective DNS in organisational policies.
Look at
Specific sections that outline employee responsibilities regarding DNS usage.
Good evidence
Includes clear directives and employee acknowledgement of these policies.
- Check 5 of 5What an auditor asks for
Ask for
Training records: Request records of training sessions about DNS protection.
Look at
The content covered and attendance records.
Good evidence
Includes recent and relevant training sessions conducted for all employees with an understanding of DNS protections.
Mappings
Closest match in ISO/IEC 27001: A.8.7, Protection against malware, which this control partially meets.
ISO/IEC 27001: 3 mappings
This control partially meets A.8.7.
ISM-1782 requires using protective DNS to block access to known malicious domains, helping prevent users and systems from reaching malware delivery sites and command-and-control domains. ISO/IEC 27001:2022 Annex A 8.7 requires implementing protection against malware, which includes a range of preventive and detective measures across endpoints, email and networks. Protective DNS under ISM-1782 strengthens Annex A 8.7 by reducing inbound malware exposure, but it does not replace endpoint anti-malware controls and user awareness required by Annex A 8.7.
This control partially meets A.8.20.
ISM-1782 requires implementing protective DNS to block resolution of known malicious domains, reducing exposure to malicious infrastructure. ISO/IEC 27001:2022 Annex A 8.20 requires securing and controlling networks and network devices, which commonly includes DNS security and network-level filtering controls. Protective DNS is a specific network security control that supports, but does not fully satisfy, the broader network governance and device security expectations in Annex A 8.20.
This control partially meets A.8.23.
Annex A 8.23 requires external website access to be managed to reduce exposure to malicious content. ISM-1782 specifies using protective DNS to block known malicious domain names, which directly implements malicious site blocking. Annex A 8.23 is broader because it does not prescribe DNS-based controls and can include methods such as proxy category filtering.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.