Use this when there is no acceptable use policy, or when the current one predates AI tools, remote work or personal devices. You get three documents in a new folder, ./acceptable-use-policy-drafting/: the staff policy itself, two to three pages in plain language (acceptable-use-policy.md); a note of the choices leadership made and how people really work today, for the people who own the policy rather than staff (decisions.md); and five quiz questions to check that a colleague understood it after one read (comprehension-check.md). This skill drafts for a human to review and sign; this skill never marks a control effective. HR and leadership approve the policy, and HR or legal confirm anything touching employment terms or monitoring.
Inputs to gather
Read before asking: the current policy or employee handbook section, device management reports, the single sign-on app list, a finance summary of software and AI subscriptions (ask for tool names and counts, not raw card records naming people), the incident log (lost devices, phishing, data sent to the wrong place) and the data classification scheme if one exists. Then ask the reader, in one message: who uses personal phones or laptops for work today, which AI tools are approved or paid for, whether staff work from abroad, and whether the company monitors devices or traffic.
Step 1: find how people really work
Look for the gaps between the rules people are told and the tools they use: subscriptions to AI assistants paid on personal cards, personal phones used for sign-in approval, file sharing apps outside the managed list, a team that works from cafes. Write each one as a fact in the decision note (decisions.md), without naming individuals. A ban on something half the staff do daily turns into a policy nobody follows; give an approved route instead.
Step 2: put the choices to the reader as decisions
List each choice with two or three options and a recommendation, and get the reader's answer before drafting:
- Devices: company devices only, personal phones allowed for email and sign-in under device management, or personal devices allowed with browser-only access.
- AI tools: which tools are approved, under which account type (company-managed accounts whose terms exclude training on inputs, versus personal free accounts), and which data classes may go in. A workable default: public and internal data in approved tools only; no customer data, personal data, credentials or source code unless the tool and use are approved for that class; a human checks output before it reaches a customer or production.
- Remote work and travel: where work is allowed, rules for public networks and shared spaces, and whether travel to some countries needs approval or a clean device.
- Personal use: what reasonable personal use of company devices and accounts looks like.
- Monitoring: what is monitored and why. Staff must be able to read this in the policy itself; in several countries monitoring also needs consultation with staff representatives, so route this decision to HR or legal.
Step 3: draft in plain language
Two to three pages. Write for the least technical person in the company: short sentences, "you" and "we", no acronyms without a gloss. Start with a document control block (owner, version, approver, approval date, next review date, twelve months is a sound default). Structure:
- Why this exists, in two sentences, and who it covers (employees, contractors, temporary staff); company devices, accounts and data remain company property.
- Using company devices and accounts.
- Personal devices.
- AI tools, with three examples of fine use and three of not-fine use drawn from the company's real work ("summarising a public article is fine; pasting a customer's export into a personal chatbot account is not").
- Working remotely and travelling.
- Email, messaging and social media.
- What to report, how and how fast: a lost device, a suspicious message, data sent to the wrong person. One channel, a time expectation in hours, and a statement that reporting fast is never punished.
- Monitoring and privacy at work.
- What happens if the rules are broken, proportionate and written with HR.
Every rule is either a "do" or a "do not" a person can follow without asking. Rules that need judgment get one sentence of reasoning and a contact.
In decisions.md, not in the staff-facing policy, record which of the company's controls or framework areas this policy supports (use the company's own control list, or a framework lookup), so the policy links back to the management system.
Step 4: test it on readers
Write five quiz questions (comprehension-check.md) that a person should answer correctly after one read ("You lost your work phone on the train. What do you do in the first hour?"). Ask the reader to have two non-technical colleagues try them, and work only from the answers the reader brings back; a missed question marks a section to rewrite. Add a short acknowledgement text for onboarding and for each material change, and name where acknowledgements are recorded (who, when, which version), usually the HR system, so awareness evidence exists without a separate spreadsheet.
What good looks like
- The best drafter checks the expense records and app list before writing the AI section, because that is where the policy and the reality differ most.
- The common mistake is a legalistic list of prohibitions copied from a template, with a blanket AI ban the company breaks daily. The tell: the policy forbids tools that appear on the company's own invoices, or staff cannot say what to do with a lost device after reading it.
- Good output fits on three pages, uses the company's own examples, gives an approved route for every common need, and lets a person act on the reporting section within the first hour of an incident.
Framework lookups
If ISMS Copilot is connected to your agent (MCP server https://account.ismscopilot.com/v1/account/mcp), ask it the framework question with create_conversation (mode think, answer_format: decision) and keep one conversation for this task. Send only a short question in your own words, show it to the user first, and never include file contents, secrets, personal data or evidence. If it is not connected, check the official text of the framework yourself; this skill does not restate it. Set it up: https://www.ismscopilot.com/mcp?ref=grcskills-acceptable-use-policy-drafting
Rules
- MUST get the reader's answer on devices, AI tools and monitoring before drafting those sections.
- MUST route monitoring and disciplinary wording to HR or legal for review.
- MUST write outputs only inside
./acceptable-use-policy-drafting/ and ask before overwriting.
- NEVER ban a tool the company depends on without naming the approved alternative.
- NEVER name individual employees or copy personal data from incident or expense records.
- NEVER approve or publish the policy on the company's behalf.