Annex A 5.10: Acceptable Use of Information and Other Associated Assets

Annex a 5.10: acceptable use of information and other associated assets requirement expects you to define, communicate, and enforce rules for how workers and third parties handle your information and assets (devices, accounts, networks, cloud services). Operationalize it by publishing an acceptable use standard, embedding it into onboarding and access workflows, and retaining evidence that people acknowledged it and violations are handled consistently. ¹

Key takeaways:

• Write asset-specific acceptable use rules that map to your information classification and key systems.
• Build enforcement into workflows: onboarding, access provisioning, device management, and offboarding.
• Keep audit-ready proof: acknowledgements, training completion, exception approvals, and incident/HR records tied to violations.

Acceptable use controls fail in audits for one reason: the organization has a policy document, but no operational mechanism to prove people follow it. Annex A 5.10 pushes you to close that gap by turning “don’t do risky things” into a set of clear, role-relevant rules for information and the assets that process it, then proving those rules are communicated and enforced. ²

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat acceptable use as a control family with three parts: (1) defined requirements (what’s allowed and prohibited), (2) adoption (how you make sure the right people see and acknowledge it), and (3) detection and response (how you identify and handle violations). Your acceptable use rules should cover employees and non-employees, corporate and BYOD devices where permitted, and high-risk channels like email forwarding, removable media, personal cloud storage, and unsanctioned AI tools.

This page gives requirement-level implementation guidance with a step-by-step build plan, evidence bundle, audit questions, and execution plan you can run through quickly and keep running.

Regulatory text

Framework requirement (excerpt): “ISO/IEC 27001:2022 Annex A control 5.10 implementation expectation (Acceptable Use of Information and Other Associated Assets).” ¹

Operator interpretation: You must establish documented rules for acceptable use of information and associated assets, communicate those rules to the people who use or manage the assets, and operate the control so misuse is prevented or addressed. This covers information in any form (digital, paper, verbal) and assets such as endpoints, applications, cloud services, accounts, network services, and removable media. ²

What auditors look for: a written standard, proof it was acknowledged, and evidence the organization can detect and act on violations in a consistent, governed way.

Plain-English interpretation of the requirement

You need a clear “rules of the road” for how staff and third parties handle company information and the tools that store or process it. The rules must be specific enough that a reasonable person can follow them without guessing, and enforceable enough that IT/SecOps/HR can apply them consistently.

A workable acceptable use standard answers:

• What can users do with company data (create, store, transmit, print, share)?
• What tools are permitted (approved apps, storage, collaboration, AI tools)?
• What is prohibited (credential sharing, shadow IT, risky exports, unauthorized monitoring, bypassing security controls)?
• What happens when a rule is broken (discipline, access removal, incident response)?

Who it applies to

Entity scope: Any organization implementing ISO/IEC 27001 that has users interacting with information and associated assets, including service organizations with customer data and multi-tenant systems. ¹

People scope (typical):

• Employees (all departments)
• Contractors, temps, interns
• Third parties with logical access (support vendors, MSPs, consultants)
• Third parties handling physical records or devices (offsite storage, repair)
• Privileged users (admins, engineers, IT, security) with stricter rules

Operational contexts you must cover:

• Corporate-managed endpoints and approved BYOD (if allowed)
• Remote work and travel
• SaaS and cloud consoles
• Collaboration channels (email, chat, file sharing)
• Data export paths (APIs, bulk downloads, reporting tools)
• Physical handling (printing, disposal, meeting rooms)

What you actually need to do (step-by-step)

1) Assign control ownership and define the control “shape”

Create a control card (one-page is fine) with:

• Owner: usually Information Security or GRC; HR and IT are key operators
• In-scope populations: employees + named third-party groups
• Trigger events: onboarding, role change, new system access, policy update, offboarding
• Operating cadence: at minimum, on hire and when updated; add periodic reaffirmation if your risk profile needs it
• Enforcement points: IAM, MDM, DLP, CASB/SSE, HR discipline process

This turns Annex A 5.10 from “policy” into an auditable control runbook. ¹

2) Define your acceptable use standard (write it like a ruleset)

Avoid vague statements (“use responsibly”). Use “allowed / prohibited / requires approval” language.

Minimum sections most auditors expect:

• Information handling basics: follow classification/labeling rules; store data only in approved repositories; encrypt where required.
• Identity and credentials: no sharing accounts; MFA required; password manager expectations; reporting of suspected compromise.
• Endpoints and software: approved software only; no disabling security agents; patching expectations.
• Email and messaging: restrictions on auto-forwarding; handling external recipients; phishing reporting.
• Data movement: removable media restrictions; upload/download rules; personal storage prohibition (or strict controls).
• Cloud/SaaS use: only sanctioned tenants; no personal accounts for business data.
• AI/tooling guardrails: define what data types cannot be pasted into public tools; require approval for new AI services.
• Monitoring and privacy notice: that corporate assets may be monitored consistent with law and policy.
• Consequences and escalation: how violations are triaged (security incident vs. HR issue), and who approves exceptions.

Tie this back to Annex A 5.10 and your ISMS policy hierarchy. ²

3) Map rules to assets and roles (make it enforceable)

Build a simple matrix:

Asset / channel	Default rule	Higher-risk roles	Technical enforcement
Laptops/desktops	Corporate management required	Admins: separate admin account	MDM baseline, EDR
Email	No external auto-forward	Finance/HR: stricter DLP	Email DLP, transport rules
File storage	Approved cloud drives only	Engineering: repo controls	CASB/SSE, access policies
Removable media	Restricted or approved only	Support: break-glass process	Endpoint control

This is where acceptable use becomes operational instead of aspirational.

4) Embed acknowledgement into onboarding and access provisioning

Operational pattern that works:

• New hire workflow in HRIS triggers: policy delivery + attestation task.
• Access provisioning in IAM includes: “acceptable use acknowledged” check before granting access to key systems.
• Third-party onboarding includes the same attestation (or contract clause + portal acknowledgement).

Make policy updates re-trigger acknowledgement for affected populations (all users or defined groups).

5) Define an exception process (or you will create shadow exceptions)

Create a lightweight exception form:

• Business justification
• Data types involved
• Compensating controls
• Time-bound expiry
• Approver(s): data owner + security + risk/compliance where needed

Track exceptions centrally. Auditors will ask how you prevent exceptions from becoming permanent policy overrides. ¹

6) Train and reinforce with targeted micro-guidance

You don’t need long training for everyone. You need role-specific reinforcement:

• Engineers: source code, secrets, repositories, production data access
• Sales/CS: customer data sharing, exports, email hygiene
• Finance/HR: payroll and sensitive personal data handling
• IT/Admins: privileged access, logging, break-glass, admin workstation rules

7) Detect violations and act consistently

Acceptable use without enforcement is a paper control. Build a minimum detection + response loop:

• Intake: DLP alerts, EDR alerts, email rule violations, SOC tickets, hotline reports
• Triage: security incident vs policy/HR issue
• Response: containment (disable account, remove device), investigation, corrective action
• Closure: root cause and preventive actions (training, control tuning)

Coordinate HR, Legal, and Security to avoid inconsistent discipline.

8) Run control health checks and remediate

Perform recurring checks focused on provability:

• Random sample: acknowledgements complete for new hires and new third-party users
• Exceptions: none expired without review
• Enforcement: top categories of violations have documented outcomes

Track gaps to closure with owners and due dates. ¹

Required evidence and artifacts to retain

Keep a tight “minimum evidence bundle” so audits don’t become scavenger hunts:

• Acceptable Use Policy/Standard (current version) with approval record and effective date
• Distribution/communication record (HRIS or LMS campaign logs)
• Attestation/acknowledgement logs (employees and applicable third parties)
• Training completion records (if you deliver training tied to acceptable use)
• Exception register with approvals, expirations, and compensating controls
• Samples of enforcement evidence:
  • DLP/EDR/email control screenshots or exported reports
  • Ticket records showing investigation and closure
  • Access removal or corrective action documentation
• Control health check results and remediation tracker

Retention period should align to your ISMS documentation retention rules and audit cycle.

Common exam/audit questions and hangups

Auditors and customer assessors commonly ask:

• “Show me the acceptable use rules for contractors and third parties with access.”
• “How do you ensure new hires acknowledge acceptable use before receiving access?”
• “What happens when someone violates acceptable use? Show examples.”
• “How do you handle BYOD, personal cloud storage, and data sync tools?”
• “Where is your exception process, and who can approve exceptions?”
• “How do you ensure privileged users follow stricter requirements?”

Hangups that cause findings:

• A policy exists, but no proof of acknowledgement.
• The policy doesn’t cover modern channels (SaaS, AI tools, collaboration).
• Violations are handled ad hoc with no documented governance trail.

Frequent implementation mistakes and how to avoid them

1. Writing a generic policy that can’t be enforced.
   Fix: convert vague statements into “allowed/prohibited/approval-required” rules and map each high-risk rule to an enforcement point.

2. Forgetting third parties.
   Fix: include acceptable use in third-party onboarding and ensure contract terms and access processes require acknowledgement.

3. No exception register.
   Fix: require time-bound exceptions with compensating controls. Review and close expired exceptions.

4. Treating this as security-only.
   Fix: align Security, IT, HR, and Legal on monitoring notice, investigations, and consequences.

5. Evidence scattered across tools.
   Fix: define a single evidence location and an export routine for LMS/HRIS/IAM logs.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this control. Practically, acceptable use gaps increase the likelihood of preventable incidents: data leakage to unsanctioned apps, credential compromise through poor user practices, and inconsistent handling of misuse that creates HR and legal risk. Annex A 5.10 is also a customer trust control in service organizations because it supports consistent handling of customer data across teams. ¹

Practical 30/60/90-day execution plan

First 30 days (establish control and stop obvious gaps)

• Name control owner and publish the control card (scope, triggers, evidence).
• Draft/refresh acceptable use standard with clear prohibited/approved rules.
• Implement acknowledgement capture for employees (HRIS/LMS) and third parties (portal or contract + attestation).
• Stand up an exception intake form and register.

Days 31–60 (embed into workflows and add enforcement)

• Add “acknowledged acceptable use” gate to access provisioning for key systems.
• Map top rules to enforcement points (MDM baseline, email forwarding controls, DLP where available).
• Create role-based guidance for privileged users, HR/Finance, Engineering, and Support.
• Define triage path for violations (Security + HR), and document it.

Days 61–90 (prove operation and make it repeatable)

• Run a control health check: sample acknowledgements, exceptions, and violation handling tickets.
• Tune detection rules and update the acceptable use standard based on observed misuse patterns.
• Prepare the audit evidence bundle and test retrieval speed (who can produce what, from where).
• If you use Daydream for GRC workflows, configure the control card, evidence checklist, and recurring health checks so audits pull from a single system of record.

Frequently Asked Questions

Does Annex A 5.10 require employees to sign an acceptable use policy?

The control expects acceptable use rules to be communicated and followed. In practice, an acknowledgement record is the simplest proof of communication and accountability during audits. ¹

How do we handle acceptable use for third parties like contractors or support vendors?

Put third parties into the same control flow: contract terms + attestation, scoped access, and monitoring aligned to the services they perform. Keep evidence that each third party user accepted the rules before access was granted.

What counts as “associated assets” under this requirement?

Treat any asset that stores, processes, or transmits information as in scope: endpoints, applications, cloud services, accounts, network services, removable media, and even paper records. ²

We allow BYOD. Do we need separate acceptable use rules?

Yes, BYOD needs explicit boundaries: what data can be accessed, required device controls, and what happens if the device is lost or the user leaves. Align those rules with what IT can technically enforce.

How specific should prohibited activities be?

Specific enough to be testable. “No credential sharing,” “no personal cloud storage for company data,” and “no external email auto-forwarding without approval” are enforceable. “Use responsibly” is not.

What evidence is most often missing in audits?

Auditors most often see gaps in acknowledgement logs, third-party coverage, and exception approvals. Keep a standard evidence bundle and confirm you can export it quickly from your HRIS/LMS/IAM.

Footnotes

1. ISO/IEC 27001 overview

2. ISMS.online Annex A control index