Why Safeguard 10.3 disable autorun matters before any other removable media control
An auditor who asks how USB drives are kept from running code on laptops is testing whether the organization has closed the simplest path into an endpoint. Safeguard 10.3 asks the enterprise to disable autorun and autoplay auto-execution for removable media, so that inserting a drive does not start a program, script or installer without a user or administrator deciding to run it. Plugging in a drive is an action people perform every day, often without thinking, and a drive prepared by an attacker, or simply infected elsewhere, can launch code the moment Windows or another operating system mounts it. That is why this setting is a sensible first step: it removes an automatic execution path before any scanning or detection tool gets involved.
Safeguard 10.3 is an IG1 safeguard, so it applies to IG1, IG2 and IG3 enterprises alike. It is a configuration setting, not a product purchase, which makes it cheap to start and easy to overlook. The hard part is keeping it true. Settings drift across device types, with Windows, macOS and Linux endpoints each storing the behavior in different places, and a setting enforced on one fleet can be overridden by a local user, a legacy image or a vendor utility installed later. The deeper problem is the asset inventory. Safeguard 1.1 and Safeguard 4.1 are listed as prerequisites for measuring 10.3, so an organization that cannot list its endpoints or does not have a secure configuration process cannot show that every asset is configured correctly.
The practical next step is to confirm three things before any further removable media work: which endpoints are in scope, which management tool applies the setting to each one, and how the organization would detect a device that falls out of line. Ask the team that owns endpoint configuration to show the policy as applied, not as written, on a sample of each device type. An illustrative check is a query that lists devices where the autorun setting is not enforced, run on a schedule and reviewed by someone who owns the exception list.
Which devices, teams and third parties fall under Safeguard 10.3 scope
Safeguard 10.3 applies to the enterprise assets that the organization has recorded and configured, so scope is set by the asset inventory and the secure configuration process rather than by the team that happens to run the endpoints. The cards below cover the device types, teams and outside parties that most often change the work, and where unlisted devices tend to hide.
Devices asset class
Safeguard 10.3 sits in the Devices asset class and the Protect security function in v8.1, so the starting question is which hardware counts as an enterprise asset that can accept removable media. Laptops, desktops, workstations and any device with a USB or optical port belong in the population. Confirm the asset class definition in your own inventory before assigning owners, because the same device can appear under different categories across tools.
Windows, macOS and Linux endpoints
Each operating system disables autorun and autoplay through a different mechanism, such as Group Policy or device policy on Windows, configuration profiles on macOS, and udev or desktop environment settings on Linux. Your measurement must cover all three, and an assessor will expect a documented setting for each platform. Ask your team which configuration method applies to each OS and whether the setting is enforced or only recommended.
Servers that accept removable media
Servers are often excluded from endpoint policies, yet some have USB ports, optical drives or virtual media mounts that staff use for maintenance. Decide whether each server is in scope and, if it is, record the reason. Physically locked data center hardware may still need the setting if removable media can be attached during an incident. Confirm with server owners which systems can receive media at all.
Kiosks and shared workstations
Kiosks, reception terminals, lab machines and shared workstations are where users insert unknown media most often, and they are frequently managed by a different team or left out of the standard image. Check whether these devices are in the inventory, whether they receive the same configuration baseline, and whether local administrators can override the setting. Treat each shared device as an asset with a named owner.
Devices owned by third parties
Contractor laptops, vendor-managed devices and devices on outsourced service desks can connect to your environment while sitting outside your direct management. Whether they fall in scope depends on your inventory and contract terms, not on who holds the device. Ask providers for evidence that autorun is disabled on any device that reaches your data, and document the requirement in the service agreement.
Prerequisites: Safeguards 1.1 and 4.1
The CIS Controls Assessment Specification lists Safeguard 1.1, the detailed enterprise asset inventory, and Safeguard 4.1, a secure configuration process, as prerequisites for measuring Safeguard 10.3. Without a complete inventory, you cannot know how many assets to measure. Without a documented configuration process, you cannot show who set the autorun value or how it stays set. Confirm both before you start the measurement.
How an assessor tests Safeguard 10.3 and what they ask to see
This table sets out how an assessor is likely to test Safeguard 10.3 against the CIS Controls Assessment Specification's Compliance metric, the share of assets properly configured to disable autorun, autoplay and auto-execute functions. Read each row as a test step, the evidence that closes it and the findings that usually cause a gap. The main takeaway is that the score depends on an accurate asset list and a documented baseline, so those two items should be ready before the assessor arrives.
| Test area | What the assessor checks | Evidence requested | Common findings |
|---|---|---|---|
| Asset list | Confirms the in-scope population of endpoints that can mount removable media, using Safeguard 1.1 as the prerequisite | Current asset inventory export with device type, operating system and owner, dated close to the test | Devices missing from the inventory, or lab and kiosk machines excluded without a documented reason |
| Configuration baseline | Checks that a written secure configuration standard requires autorun and autoplay to be disabled, tied to Safeguard 4.1 | Hardening standard or benchmark profile, change history and approval record | No written standard, or a standard that covers only some operating systems |
| Policy or registry setting on sampled devices | Inspects the group policy, MDM profile or registry value on a sample of endpoints to confirm autorun and autoplay are off | Screenshots or exported policy results, or the configuration query output for each sampled device | Setting applied to one domain or group but not others, or overridden by a local policy |
| Coverage of auto-execute functions | Confirms the setting covers removable media and the auto-execute behavior the Safeguard names, not only one trigger | Policy settings listing each removable media behavior that is disabled | Autoplay disabled while autorun remains enabled, or the reverse |
| Continuous compliance reporting | Looks for evidence that the setting is checked after deployment, not only at rollout | Recent compliance report or dashboard showing pass and fail counts per device | Reports exist but are stale, or no owner reviews failing devices |
| Exceptions | Reviews any device where the setting is intentionally relaxed and whether the exception is approved and time-limited | Exception register with business reason, approver, compensating control and expiry date | Undocumented exceptions discovered during device sampling |
| Sampling method | The auditor selects its own sample, and the method and sample size are its decision | Ability to produce any sampled device's configuration on request | Sample includes devices the team did not expect, exposing gaps in the asset list |
| Compliance metric | Calculates the share of assets properly configured against the in-scope population | Reconciled figures showing the numerator and denominator | Denominator smaller than the true asset count, which inflates the result |
How to implement autorun controls across the fleet, step by step
This sequence turns Safeguard 10.3 from a written intent into a configuration that is deployed, tested on a pilot group, exception-managed and verified across every in-scope device, with evidence that an assessor can trace.
Confirm the asset inventory and secure configuration process
Before any setting changes, confirm that the detailed enterprise asset inventory (Safeguard 1.1) lists every endpoint that can accept removable media, and that a documented secure configuration process (Safeguard 4.1) exists and is owned by a named person. The CIS Controls Assessment Specification treats both as prerequisites for measuring 10.3, so an assessor will ask for them first. The output is a confirmed asset list by operating system and a reference to the approved configuration process. The step is done when every device in scope maps to an owner and a platform.
Write the autorun standard for each platform
Write a short standard that states the target setting for each platform in use. For Windows, this usually means a Group Policy setting or an MDM profile that disables AutoRun and AutoPlay for removable drives. For macOS, define the equivalent restriction in your MDM tool. For Linux desktops, define the desktop setting that prevents automatic mounting and execution. Name the exact setting, the policy object or profile name and the owner who approves changes. Confirm each setting against your vendor documentation, because platform names and menu paths change between releases. The output is a written standard that is version-controlled and signed off by the security owner.
Build and deploy the policy to a pilot group
Create the Group Policy object, MDM profile or desktop configuration from the standard and assign it to a small, representative pilot group that includes different device types, user roles and locations. Watch for side effects, such as users who depend on removable media for legitimate work or software that expects autoplay. The output is a pilot result record listing which devices applied the setting, which failed, which users reported problems and what changes were made. Do not move to the full fleet until the pilot record shows the setting applies cleanly and the exceptions are understood.
Roll out the setting across the fleet
Extend the assignment from the pilot group to all in-scope asset groups in waves, starting with the lowest-risk groups. Keep the change record for each wave, including the date, the scope and the person who approved it. Notify users and the service desk before each wave so that support requests can be matched to the change. The output is a deployment log that shows which assets received the policy and when. The step is complete when the policy is assigned to every device in the asset inventory that can accept removable media.
Handle exceptions through documented approval
Some devices or users will need removable media with auto-execution enabled, or will need a different configuration for a business reason. Record each exception in a register that states the asset, the requester, the business justification, the compensating control, the approver and a review date. The approver should be someone outside the team that requested the exception. Confirm that the register is reviewed on a schedule the organization sets, and that expired exceptions are closed. The output is an exception register that an assessor can sample against live configurations.
Verify settings and track drift
Check the deployed configuration against the standard on a recurring basis, using your endpoint management console, a compliance scanner or an open-source tool. Wazuh Security Configuration Assessment can check endpoints against YAML policies that are largely based on CIS benchmarks and can be extended with custom checks. Fleet policies can ask each device a yes or no question through osquery, and its policies page shows which devices pass or fail. Compute the Compliance metric the assessment specification describes: the share of assets properly configured. The output is a drift report that lists non-compliant devices, the cause and the remediation ticket. Confirm the scanner's policy content and check frequency in your own environment before relying on it as evidence.
Retain evidence for the assessor
Collect the standard, the deployment log, the pilot record, the exception register and the drift reports into one evidence folder with a dated index. Keep the most recent scan results and a sample of configuration exports from individual devices, because an assessor will often sample endpoints rather than accept a summary. Ask your auditor, or the framework owner, which evidence formats and retention periods they expect. The output is an evidence package that shows the setting was designed, deployed, exception-managed and continuously measured. The step is complete when someone outside the implementation team can trace a single device from the inventory to its live setting.
Evidence that passes a Safeguard 10.3 audit and how to keep it current
An assessor testing Safeguard 10.3 looks for proof that autorun and autoplay are off on the assets in scope, and that the setting is governed, measured and changed deliberately. The six artifacts below connect the written standard to the device-level evidence that shows it is working. Confirm the refresh cadence and retention requirements with your auditor and your own policy owner, since they depend on your environment and scheme.
Written configuration standard
The document states which removable media behavior is disabled, on which asset classes, and under which owner. It should name the autorun and autoplay settings for each operating system in your fleet, so an assessor can compare the written requirement against what the endpoints actually run. Link it to the secure configuration process that Safeguard 4.1 requires, because the assessment specification treats that process as a prerequisite. Review it when operating systems or endpoint standards change.
Policy export or MDM profile
This artifact proves the standard was applied. Export the Group Policy, configuration profile or management policy that sets the autorun and autoplay values, and keep the version history that shows which settings were active on which dates. An assessor checks that the exported values match the written standard, not just that a policy exists. Confirm that the profile is assigned to the device groups in scope, since an unassigned profile looks identical in a document review.
Per-device compliance report
The assessment specification scores Safeguard 10.3 with a Compliance metric: the share of assets properly configured to disable autorun, autoplay and auto-execute functions. Produce a report that lists each asset in the inventory, its result and the date it was checked. Run it from your endpoint management or configuration assessment tool, and reconcile its asset count against the Safeguard 1.1 inventory so that missing devices do not inflate the percentage. Refresh it on a schedule you can defend to the assessor.
Exception records with approvals
Some devices, such as kiosks, lab systems or equipment that depends on removable media, may need autorun enabled or a different setting. Record each exception with the asset, the business reason, the compensating control, the approver and an expiry or review date. An assessor will ask whether exceptions are rare, justified and reviewed, and an undocumented exception on a single device can fail the compliance measure for the whole fleet. Confirm with your own risk owner how exceptions are approved and reviewed.
Configuration drift and check results
Automated configuration checks show whether an endpoint still has autorun disabled after updates, reimaging or user changes. Keep the scan results and the rule set that produced them, including any custom policies you added to a standard benchmark. Wazuh Security Configuration Assessment, for example, uses YAML policies that check files, registry keys and processes and recommend remediation, so its output can show drift over time. Confirm that the rule version matches the configuration standard in force on each date.
Change history and remediation tickets
Every change to the autorun setting, the policy that carries it or the exceptions list should trace to an approved request and a completed remediation record. Keep the ticket, the approver, the before and after values and the date. Assessors use this trail to confirm that the setting is managed through the secure configuration process rather than adjusted ad hoc, and that drift found in compliance reports was investigated and closed. Retention periods for this trail should follow your own policy and any contractual or regulatory requirement you carry.
What meeting Safeguard 10.3 costs in money and effort
This table breaks down the cost components of meeting Safeguard 10.3 for autorun on removable media, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to build a scope and quote request, since no published price or duration is attached to this Safeguard. The main takeaway is that most of the effort sits in configuration consistency and exception handling, not in the setting itself.
| Cost component | One-time or recurring, who is paid | What drives it up or down |
|---|---|---|
| Configuration engineering time | One-time for the baseline, then recurring for changes. Paid to internal platform staff or an implementation partner | Up with fleet size and device diversity (Windows, macOS, Linux). Down with a standard image or existing MDM policy that already sets the autorun value |
| Endpoint management licenses | Recurring. Paid to a commercial MDM or endpoint suite vendor, or none when a self-hosted open-source tool covers the check | Up with per-device commercial pricing. Down where existing MDM already enforces the setting, or where self-hosted tooling such as Fleet or Wazuh is used |
| Compliance reporting and evidence upkeep | Recurring. Paid to internal compliance staff or a partner preparing evidence | Up with the number of reporting cycles and asset classes. Down with automated pass or fail reports exported on a fixed schedule |
| Exception handling | Recurring. Paid to IT operations and the security owner who approves exceptions | Up with exception volume, such as legacy devices or kiosks that need removable media autorun. Down with a documented exception process and time-limited approvals |
| Asset inventory prerequisite upkeep | Recurring. Paid to internal asset management staff | Set by the Safeguard 1.1 inventory the CAS lists as a prerequisite. Up with unmanaged or shadow endpoints. Down with a current inventory that matches what is measured |
| External review of configuration | Occasional. Paid to an independent reviewer or implementation partner, if used | Up with the number of sites and the depth of sampling requested. Down with a fixed, written scope agreed before work starts |
| Auditor sampling effort | Recurring at each assessment. Paid to the independent auditor or assessor, not to DeployOpen | Up with sample size and the number of endpoint populations in scope. Down with clean, exportable configuration records that show the Compliance metric per asset |
Who does what on Safeguard 10.3: your team, a partner and the auditor
Your organization owns Safeguard 10.3. That means deciding that removable media auto-execution is switched off, writing the standard that says so, approving the settings and keeping a record of any device or user group that needs an exception. Accountability cannot be handed to a vendor, and an auditor will ask who signed off the requirement and who reviews the exception register.
- Ownership and approval: Name an accountable owner for the endpoint configuration standard and record who approved the autorun setting.
- Standard and scope: Confirm which asset classes and operating systems the standard covers, using the asset inventory from Safeguard 1.1 and the configuration process from Safeguard 4.1.
- Exception register: Record every approved exception with a reason, an owner, an expiry date and a compensating measure.
- Operational review: Decide how often failing endpoints are reviewed and who acts on them.
- Prerequisite confirmation: Confirm that the inventory and configuration process exist before anything else is measured.
Before engaging anyone, confirm that you can name the owner, the approver and the reviewer for each of these points.
An implementation partner such as DeployOpen can prepare the technical side of Safeguard 10.3: the Group Policy or management profile that disables autorun and autoplay, the monitoring that shows whether each asset complies, and the evidence package that explains both. The partner works inside your environment under a fixed written scope, and the deliverables should be listed in that scope before work begins.
- Configuration build: Prepare and test the policy or profile for each endpoint platform in your environment.
- Compliance monitoring: Set up a check that reports the share of assets with autorun and autoplay disabled, mirroring the Compliance metric in the assessment specification.
- Evidence package: Assemble exports, screenshots, change records and configuration baselines, with a short narrative that maps each item to the Safeguard.
- Documentation and handover: Deliver runbooks so your staff can operate and update the setting after the engagement ends.
- Limits of the role: The partner prepares evidence but cannot issue any report or certificate, and it cannot be the party that tests its own configuration for the audit.
Ask any prospective partner to state in writing which deliverables are included and which remain with your staff.
The independent auditor or assessor tests whether Safeguard 10.3 is in place and operating. Only an independent party can issue a report, attestation or certificate, and its independence is what gives the result weight. Its work usually includes reviewing your documented standard, sampling endpoints, and checking the evidence against the measures in the CIS Controls Assessment Specification.
- Test design: The assessor chooses samples, often across device types and locations, and tests them directly rather than relying only on your summary.
- Evidence review: It checks that configuration exports, monitoring results and exception records agree with each other and with the asset inventory.
- Exception handling: It tests whether exceptions were approved, time-limited and reviewed.
- Reporting: Any report or certificate comes from the assessor, not from your team or your partner.
- Independence line: An assessor cannot test configuration that its own firm built, so the partner's role and the assessor's role should be kept apart from the start.
Before the engagement, confirm the assessor's scope, sampling approach and the evidence it expects in advance.
Where organizations fall short on autorun controls and how to close each gap
Safeguard 10.3 looks simple on paper, yet assessors usually find the same few gaps: the setting applied unevenly, overridden locally, measured against no inventory, or proven only by a screenshot. Each card below names one gap, why it matters for the Compliance metric in the assessment specification, and the closing action the organization owns.
Setting applied to servers only
Teams often harden servers first and assume workstations inherit the same behavior. Many workstations are laptops that join and leave the network, so they can miss a policy that was pushed to a narrower group. Confirm that the autorun and autoplay settings apply to every device class that accepts removable media, including laptops and shared kiosks. Check the result on a sample of each group rather than trusting the policy definition alone.
Local settings overriding policy
A central policy can be set correctly while a local user, legacy script or older image re-enables autoplay on the device. The Compliance metric counts assets that are properly configured, so a single overridden device weakens the result on every report. Compare the effective setting on each endpoint with the intended policy, not only the policy object. Schedule that comparison and treat drift as a finding to fix.
No asset inventory to measure against
The Compliance metric is a share of assets, so the denominator must be a complete list of enterprise assets. Safeguard 1.1 and Safeguard 4.1 are prerequisites that many organizations have not finished. Without them, a compliance percentage has no reliable base, and unmanaged devices never appear in the count. Reconcile the endpoint management console against the asset inventory before reporting any autorun result.
Exceptions without approval
Some engineering or media-production teams need autorun behavior for specific hardware or software. When those exceptions live in a chat thread or a local configuration, they become invisible to assessors and remain in place after the reason ends. Require a written exception with an owner, a business reason, a compensating control and an expiry date, then record each one in the asset inventory. Review open exceptions on a fixed schedule.
A screenshot as the only evidence
A screenshot proves one device at one moment and does not show the rest of the fleet. Assessors usually want to see the policy definition, its scope and a current compliance view across assets. Endpoint configuration tools can produce that view. For example, Fleet policies are yes or no osquery questions whose results show which devices pass or fail, and Wazuh Security Configuration Assessment checks endpoints against YAML policies. Keep exported pass or fail results over time, and confirm with the vendor how each tool records and retains them.
Confusing 10.3 with 10.4
Safeguard 10.3 requires disabling autorun and autoplay. Safeguard 10.4, an IG2 Safeguard, goes further by having anti-malware software scan removable media automatically. Disabling autorun does not prove that media is scanned, and a scanning rule does not replace the 10.3 setting. Document 10.3 and 10.4 as two separate controls with separate evidence, and confirm which Implementation Group your enterprise is assessed against. The Navigator maps 10.3 to NIST SP 800-53 Rev. 5 MP-7 and ISO/IEC 27001:2022 Annex A 7.10; confirm both mappings against the current CIS Controls Navigator before you cite them.
Common questions about Safeguard 10.3 cost, effort and audit evidence
How much effort does it take to disable autorun for removable media?
The effort is mostly configuration work plus proving it everywhere, and it scales with the number of enterprise assets rather than with the complexity of the setting itself. Disabling autorun and autoplay is a configuration change, so the main drivers are how many endpoint types you run, whether one policy can reach all of them, and how many exceptions must be documented. Effort also depends on the prerequisites. The CIS Controls Assessment Specification lists Safeguard 1.1 (detailed asset inventory) and Safeguard 4.1 (secure configuration process) as prerequisites for measuring 10.3, so an organization without a current asset inventory or a documented configuration process will spend time building those first. Ask any provider to break the effort into inventory, policy design, rollout, verification and evidence collection.
Can our own team disable autorun without an outside partner?
Yes, most internal IT teams can make this change themselves, because it is a standard configuration setting that can be applied through existing endpoint management. Outside help is optional. The parts that often benefit from extra hands are building a reliable asset inventory to measure against, producing a consistent set of configuration policies across mixed operating systems, and assembling evidence in a form an assessor can test. If you do it in-house, assign an owner for the configuration baseline, confirm which device groups the policy covers, and keep the verification results with the change record. An implementation partner can prepare systems and evidence under a written scope, but the organization still owns the control.
How long does it take to disable autorun across our fleet?
The duration depends on fleet size, device diversity and how many groups need separate handling, so no general timeline applies. A small, uniform fleet managed from one console can often be configured quickly, while a large environment with legacy systems, remote endpoints and exceptions takes longer to roll out and verify. Do not rely on a generic number. Ask for a timeline in a written scope that states the asset count, the operating systems in scope, the prerequisite work and the verification method. Fixed-scope engagements agree deliverables and timelines in writing before work starts, which is the right basis for comparing offers.
What does the work need from our team?
The work needs input from three groups: the people who own endpoint management, the people who own the asset inventory, and the people who will answer for the configuration baseline. Endpoint administrators apply and test the policy. Asset owners confirm which devices are in scope and where exceptions, such as kiosks or systems that depend on autorun, are justified. Governance or security staff approve the documented configuration process and keep the records an assessor will request. Plan for time from each group during rollout and for periodic review afterward, because the Compliance metric measures the share of assets properly configured, and that share changes as new devices join the fleet.
How does Safeguard 10.3 differ from Safeguard 10.4?
Safeguard 10.3 disables autorun and autoplay for removable media, while Safeguard 10.4 requires anti-malware software to scan that media automatically. In short, 10.3 removes the automatic execution path, and 10.4 adds inspection of the media when it is connected. Safeguard 10.3 sits in Implementation Group 1, so it applies to IG1, IG2 and IG3 enterprises. Safeguard 10.4 is added at IG2. An organization that meets 10.3 alone has closed one automatic route but has not yet added scanning, so the two are best planned together where IG2 applies.
Does a tool alone satisfy Safeguard 10.3?
No. A tool can apply or check the setting, but Safeguard 10.3 is met by a configuration that is in place across the assets it covers and that can be shown to be in place. A scanning or endpoint management tool produces evidence, such as a configuration check result, yet the organization must still define the required setting, assign ownership, apply it to the right devices and act on failures. For example, Wazuh Security Configuration Assessment uses YAML policies, mostly based on CIS benchmarks, to check endpoint configuration and recommend remediation, and Fleet policies ask yes or no questions of devices through osquery and show which devices pass or fail. Confirm with each vendor whether a specific policy checks the exact autorun and autoplay settings on your operating systems before relying on it.
How DeployOpen works on Safeguard 10.3
DeployOpen approaches Safeguard 10.3 Disable autorun for removable media as a configuration change that has to be proven on every in-scope endpoint, not just switched on in one policy. We scope the asset population, prepare the prerequisite inventory and secure configuration process, and build the setting into the endpoint platform so the evidence can be produced on request. The organization owns the control, and an independent auditor or assessor decides whether the evidence is sufficient.
How we scope
- Written scope names the endpoint populations, operating systems and asset classes where autorun and autoplay must be disabled.
- We confirm which asset inventory and secure configuration process the organization already has, since Safeguards 1.1 and 4.1 are prerequisites for measuring 10.3.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer.
How we build
- We configure the autorun and autoplay settings through the organization's chosen endpoint management approach, applied consistently across in-scope devices.
- We set up open-source compliance checks, such as Wazuh Security Configuration Assessment policies or Fleet yes-or-no policies, to report whether each device is configured correctly.
- We test the setting on representative devices, including removable media insertion, to confirm that auto-execute does not occur before handover.
How we hand over
- Documentation records the configuration baseline, the compliance check logic and the exception process for devices that cannot be changed.
- Evidence packs show the per-device pass or fail results that support the Compliance metric in the CIS assessment specification.
- The organization receives runbooks and knows who signs off exceptions, so the evidence remains usable at the next independent assessment.
How we support
- Retainer support can keep compliance checks current as operating systems, endpoint builds and fleet membership change over time.
- We can re-run tests after upgrades or policy changes and update documentation for the next review cycle.
- We prepare evidence for assessors but do not issue audit reports or certifications, which remain the role of independent auditors and certification bodies.
