12 Information Security Policy Examples for 2026

This post gives 12 information security policy examples. Each one has sample clauses, implementation tips and a mapping to ISO 27001:2022, NIST CSF 2.0 and SOC 2. Two summary tables let you scan every policy and its controls in one place.

It is written for the people who draft or update these documents: security and IT leads preparing for ISO 27001 or SOC 2, and teams answering customer security reviews. ResponseHub draws on policies like these to write cited answers to security questionnaires, so keeping them current pays off twice.

Common information security policies include data classification, access control, password and authentication, incident response, acceptable use, BYOD, remote work, third-party and vendor security, security awareness and training, encryption and data protection, AI acceptable use, and clean desk and clear screen. Most sit under one top-level information security policy.

What is an information security policy?

An information security policy is a set of rules, approved by management, that states how an organisation protects its information and the systems that hold it. A top-level policy sets direction and assigns responsibility; topic-specific policies below it cover areas such as access control, encryption and acceptable use.

ISO/IEC 27001:2022 clause 5.2 requires top management to establish an information security policy that suits the organisation’s purpose, includes information security objectives or a framework for setting them, commits to meeting applicable requirements and to continual improvement, and is documented, communicated internally and available to interested parties as appropriate. Annex A control 5.1 expects that top-level policy plus topic-specific policies, approved by management, published, communicated to and acknowledged by relevant personnel, and reviewed at planned intervals.

NIST SP 800-12 Rev. 1 groups policy into three types: program policy, issue-specific policy and system-specific policy. The labels EISP (enterprise information security policy), ISSP and SysSP for the same split come from Whitman and Mattord’s Principles of Information Security rather than NIST. Most of the 12 examples in this post are issue-specific policies that sit under one program policy.

Start the top-level document with our free Information Security Policy generator, then add the topic-specific policies your risk assessment calls for.

What changed for information security policies in 2026

• ISO/IEC 27001:2013 certificates expired on 31 October 2025, so the 2013 edition is no longer valid for certification. The 2022 edition has 93 Annex A controls in four themes (organisational, people, physical and technological), and every mapping in this post now uses 2022 numbering.
• NIST CSF 2.0 (February 2024) added the Govern function and replaced the old PR.AC and PR.IP subcategories. The mappings here use CSF 2.0 IDs, and you can read a plain-English tour in our guide to what NIST CSF is.
• NIST SP 800-63B-4 (August 2025) requires at least 15 characters for passwords used as the only factor and at least 8 when used with another factor, prohibits composition rules such as forced symbols, and recognises synced passkeys at authentication assurance level 2.
• NIST SP 800-61 Rev. 3 (April 2025) superseded the Computer Security Incident Handling Guide and aligns incident response with CSF 2.0.
• The EU AI Act’s Article 4 on AI literacy has applied since 2 February 2025. Providers and deployers must ensure staff who operate AI systems on their behalf have a sufficient level of AI literacy.
• The UK NCSC’s post-quantum migration timeline asks organisations to complete discovery and an initial plan by 2028, migrate their highest-priority services by 2031 and finish by 2035.

1. Data Classification Policy

A Data Classification Policy sorts organisational data by sensitivity, value and criticality. That structure decides the controls for handling, storing, transmitting and disposing of each type of information, so protection is proportionate. Without it, teams tend to over-protect trivial data or under-protect their most important assets. If you need a starting point, our free Data Management Policy generator builds a tailored policy in minutes.

Data classification underpins access control, data loss prevention and incident response. For a deeper look at building classification systems that people actually follow, see our guide on building data management policies that actually get followed. A financial services firm classifies customer financial records as Restricted, which requires strong encryption and strict access, and public marketing material as Public, which needs little protection.

Sample Policy Clauses

• 1.1 Classification levels: All company data is classified as Public, Internal, Confidential or Restricted. Data owners assign the classification for data under their control.
• 1.2 Handling requirements: Restricted data is encrypted at rest and in transit. Access is granted on a need-to-know basis and requires multi-factor authentication.
• 1.3 Labelling: Documents and storage media holding Confidential or Restricted data are labelled with their classification level.

Customisation and Implementation Tips

Start with a small number of levels. Involve department heads in classification, because they understand their data’s context. Train staff on their responsibilities, use data loss prevention tooling to find and label data, and review classifications each quarter.

Mapping to Security Frameworks

• ISO 27001:2022: A.5.12 (Classification of information), A.5.13 (Labelling of information)
• NIST CSF 2.0: ID.AM-05, PR.DS-01 (asset prioritisation by classification; confidentiality, integrity and availability of data at rest)
• SOC 2: CC6.1 (Logical and physical access controls), C1.1 (Confidentiality)

2. Access Control Policy

An Access Control Policy sets the rules for granting, managing and revoking access to systems and data. It enforces least privilege, giving users only the access their role needs, which limits the damage from a compromised account or an insider.

The policy governs who can reach what, and why. A bank lets tellers process transactions but reserves large loan approvals for managers. Identity platforms such as Microsoft Entra ID or Okta enforce these rules through conditional access and role-based permissions. For why access control fails at implementation and how to fix it, read our post on access control beyond least privilege, or start with our free Access Control Policy generator.

Sample Policy Clauses

• 2.1 Least privilege: Access rights are granted on the principle of least privilege and limited to what an individual’s role requires.
• 2.2 Access reviews: Data and system owners review access rights quarterly. Access that is no longer needed is revoked within 24 hours of identification.
• 2.3 Privileged access: Administrative and privileged accounts require multi-factor authentication, are logged and monitored, and use time-limited sessions with explicit approval.

Customisation and Implementation Tips

Map roles to the access each one needs. Enforce MFA on privileged accounts and remote access. Automate access reviews so permissions do not accumulate, and use identity governance tooling to provision and deprovision accounts in step with your HR joiner, mover and leaver process.

Mapping to Security Frameworks

• ISO 27001:2022: A.5.15 (Access control), A.5.18 (Access rights), A.8.2 (Privileged access rights)
• NIST CSF 2.0: PR.AA-01, PR.AA-05 (identity and credential management; access permissions managed with least privilege and separation of duties)
• SOC 2: CC6.1, CC6.2, CC6.3 (Logical access provisioning, modification and removal)

3. Password and Authentication Policy

A Password and Authentication Policy sets the standards for credentials and for the factors that back them. Current guidance favours length, screening against known-compromised passwords, and multi-factor authentication over forced complexity and scheduled expiry.

This policy protects the entry points to company data. Following NIST SP 800-63B-4, a long passphrase such as “correct-horse-battery-staple” beats a short complex string such as “P@ssw0rd1!”: it is easier to remember and harder to brute-force. A strong authentication standard is a core part of any broader Information Security Policy.

Sample Policy Clauses

• 3.1 Password construction: Passwords used as the only authentication factor are at least 15 characters. Where MFA is enforced the minimum is 8, and at least 12 for systems in PCI DSS scope (requirement 8.3.6). Systems accept at least 64 characters and check new passwords against a list of known-compromised values. There are no composition rules and no scheduled expiry; a change is forced only on evidence of compromise.
• 3.2 Phishing-resistant MFA: Administrator and privileged accounts use phishing-resistant MFA, such as passkeys or FIDO2 security keys.
• 3.3 Password protection: Passwords are never written down, stored in plaintext or shared, including with IT support. All staff use a company-approved password manager.
• 3.4 Coverage: MFA is enabled on every company system that supports it, and always for remote access and access to sensitive data.

Customisation and Implementation Tips

Adopt the SP 800-63B-4 approach: length over complexity, no arbitrary expiry, and screening against breached-password lists. Provide a corporate password manager so staff generate unique passwords for every service, and use breach-monitoring services to catch exposed credentials.

Mapping to Security Frameworks

• ISO 27001:2022: A.5.17 (Authentication information), A.8.5 (Secure authentication)
• NIST CSF 2.0: PR.AA-01, PR.AA-03 (identity and credential management; authentication of users, services and hardware)
• SOC 2: CC6.1 (Logical and physical access controls)

4. Incident Response Policy

An Incident Response Policy sets a structured way to manage a security breach or attack. It defines how incidents are identified, reported, investigated and resolved, so the response is fast and coordinated and damage is limited.

The policy names the roles of the incident response team, escalation paths and communication plans. A healthcare organisation details the first steps for a possible patient-data breach; a software company focuses on containing data exfiltration. Our free Incident Response Plan generator creates a structured plan for your organisation.

Sample Policy Clauses

• 4.1 Identification: Any employee who sees a possible security incident reports it immediately to the IT help desk or the designated security contact.
• 4.2 Team activation: On a confirmed high-severity incident, the incident response lead activates the team and starts containment.
• 4.3 Personal data breaches: Suspected personal data breaches go to the data protection officer or privacy lead immediately, so the 72-hour notification deadline under UK GDPR and EU GDPR Article 33 can be assessed.
• 4.4 Evidence preservation: Responders isolate affected systems and take forensic images before remediation.
• 4.5 Post-incident review: A review is held within 48 hours of resolution to capture lessons learned.

Customisation and Implementation Tips

Set up the incident response team and its roles before an incident. Write playbooks for phishing, malware and denial-of-service events. Run tabletop exercises each quarter. NIST SP 800-61 Rev. 3 sets out how to build and run the process, including contact lists and out-of-band communication.

Mapping to Security Frameworks

• ISO 27001:2022: A.5.24 to A.5.28 (Incident management planning, assessment, response, learning and evidence), A.6.8 (Information security event reporting)
• NIST CSF 2.0: DE.AE-02, RS.MA-01, RS.CO-02 (adverse events analysed; response plan executed; stakeholders notified)
• SOC 2: CC7.3, CC7.4, CC7.5 (Evaluating, responding to and recovering from incidents)

5. Acceptable Use Policy

An Acceptable Use Policy sets the rules for using company IT: computers, networks, internet access, email and software. It states what responsible use looks like, protects company assets and reputation, and explains the consequences of misuse.

The policy reduces risk from human error and from malicious insiders. It prohibits using company networks for illegal activity such as copyright infringement, and defines reasonable personal use during work hours. Staff acknowledge it at onboarding. Where staff want to use AI tools, policy 11 sets the rules. An AUP works best alongside a broader Information Security Policy that sets the governance framework.

Sample Policy Clauses

• 5.1 Prohibited uses: Company systems are not used for transmitting harassing material, fraud, intentionally distributing malware, or breaking the law.
• 5.2 Personal use: Occasional personal use of company internet and email is allowed if it does not interfere with work, consume significant resources or breach another policy.
• 5.3 Monitoring and privacy: The company may monitor use of its IT resources to check compliance. Staff have no expectation of privacy in information created, stored, sent or received on company systems.
• 5.4 Social media: Staff do not present personal opinions as the company’s, and do not disclose confidential or proprietary information.

Customisation and Implementation Tips

Write the AUP in plain language. Require every new and existing employee to read and acknowledge it. Communicate monitoring openly. Review it at least annually to cover new technologies and threats, and enforce it consistently.

Mapping to Security Frameworks

• ISO 27001:2022: A.5.10 (Acceptable use of information and other associated assets)
• NIST CSF 2.0: GV.PO-01, PR.AT-01 (organisational cybersecurity policy; personnel awareness and training)
• SOC 2: CC1.1 (Integrity and ethical values), CC2.2 (Internal communication of policies)

6. Bring Your Own Device (BYOD) Policy

A BYOD Policy sets the security requirements for personal devices, such as phones, laptops and tablets, that access company data, networks and applications. It balances the flexibility staff want against the need to protect information, and defines the controls that manage the risk.

Without a BYOD policy, organisations face data leakage, malware and compliance gaps. A software firm might let developers use personal laptops but require a Mobile Device Management (MDM) solution to enforce encryption and hold company data in a secure container. BYOD rules belong inside a wider Information Security Policy.

Sample Policy Clauses

• 6.1 Enrolment: Personal devices are enrolled in MDM and meet minimum security requirements, including a supported operating system, before they access company data.
• 6.2 Security controls: Devices have a strong passcode or biometric lock, full-disk encryption, and current company-approved anti-malware software.
• 6.3 Acceptable use: Devices used for work are not jailbroken or rooted, and do not install applications from untrusted sources.
• 6.4 Lost or stolen devices: Staff report a lost or stolen device to the security team immediately. The company may remotely wipe company data from it.

Customisation and Implementation Tips

Deploy an MDM or unified endpoint management tool to enforce controls centrally. Define which devices and data types are in scope. Use containerisation to separate company data from personal apps, document what the company can and cannot monitor, and train staff on device-loss procedures.

Mapping to Security Frameworks

• ISO 27001:2022: A.8.1 (User endpoint devices), A.6.7 (Remote working)
• NIST CSF 2.0: PR.AA-03, PR.PS-01 (device authentication; configuration management)
• SOC 2: CC6.1 (Logical and physical access controls), CC6.7 (Restricting the movement of information to authorised users)

7. Remote Work Security Policy

A Remote Work Security Policy sets the rules for protecting company data and systems when staff work outside the office. It addresses home networks, personal spaces and travel, and keeps security consistent wherever people work.

The policy addresses insecure Wi-Fi, device theft and viewing by others in shared spaces. A software company requires connections through a managed VPN or zero-trust service and endpoint protection on any device that reaches company resources. Use our free Information Security Policy generator to build a policy that includes remote-work provisions.

Sample Policy Clauses

• 7.1 Secure connectivity: Remote access to internal systems goes through the company VPN or zero-trust network access (ZTNA) service. Split tunnelling is used only where the security team has approved it.
• 7.2 Home network security: Home wireless uses WPA2 or WPA3, with WPA3 where the equipment supports it, and staff change the default router administrator credentials.
• 7.3 Physical security: Company devices are secured when unattended, and staff take reasonable steps to stop others viewing their screen in public.

Customisation and Implementation Tips

Provide company-managed equipment where you can. Deploy endpoint detection and response on remote devices. Train staff on remote-specific risks such as phishing and screen privacy, and provide privacy screens for laptops.

Mapping to Security Frameworks

• ISO 27001:2022: A.6.7 (Remote working), A.7.9 (Security of assets off-premises), A.8.1 (User endpoint devices)
• NIST CSF 2.0: PR.AA-03, PR.IR-01 (device authentication; networks protected from unauthorised access)
• SOC 2: CC6.6 (Logical access from outside the system boundary), CC6.7 (Restricting information movement)

8. Third-Party and Vendor Security Policy

A Third-Party and Vendor Security Policy manages the risk that comes through the supply chain. It sets the security requirements, due diligence and monitoring for any vendor, contractor or service provider that accesses, processes or stores company data.

The policy runs the vendor risk lifecycle, from onboarding and assessment to termination and data destruction. A software company requires its cloud host to provide a SOC 2 Type II report, and a marketing agency that handles customer data to sign a data processing agreement. AI and large-language-model providers, and any subprocessors that process company data, are in scope on the same terms. Because third parties count as associated persons under UK law, this policy connects to your financial-crime controls, such as a Corporate Criminal Offence (CCO) policy. A strong vendor programme starts with a solid Information Security Policy.

Sample Policy Clauses

• 8.1 Risk assessment: New vendors complete a security risk assessment before they get access to company systems or data. The depth of the assessment matches the vendor’s access and the sensitivity of the data.
• 8.2 Contractual requirements: Vendor contracts include a security addendum covering incident notification, data protection, audit rights and regulatory compliance.
• 8.3 Continuous monitoring: High-risk vendors are reassessed annually. The company may terminate vendors that fail to meet their security obligations.

Customisation and Implementation Tips

Tier vendors by their access to sensitive data, and set due diligence by tier: a SOC 2 report for high-risk cloud vendors, a shorter questionnaire for low-risk suppliers. Keep a central vendor inventory, and put incident-notification timelines into contracts.

Mapping to Security Frameworks

• ISO 27001:2022: A.5.19 to A.5.23 (Supplier relationships, agreements, ICT supply chain, monitoring and cloud services)
• NIST CSF 2.0: GV.SC-05, GV.SC-06, GV.SC-07 (supply-chain requirements, due diligence and supplier risk management)
• SOC 2: CC9.2 (Assessing and managing vendor and business partner risk)

9. Security Awareness and Training Policy

A Security Awareness and Training Policy sets the organisation’s commitment to educating its workforce, so staff know their role in protecting company assets. It mandates ongoing training and addresses the human element that even strong technical controls depend on.

The policy makes security a shared responsibility beyond the IT team. A healthcare provider mandates annual patient-data training; a software firm runs monthly phishing simulations. Staff decisions are a common factor in security incidents, which is why training and reinforcement matter. Training is grounded in your Information Security Policy, and AI literacy under policy 11 belongs in the same programme.

Sample Policy Clauses

• 9.1 Mandatory participation: All employees, contractors and relevant third parties complete security awareness training at onboarding and every year after.
• 9.2 Phishing simulations: The company runs periodic, unannounced phishing simulations and tracks results for reporting.
• 9.3 Role-based training: People in specific roles, such as developers and system administrators, receive training for their security responsibilities.

Customisation and Implementation Tips

Use real-world scenarios rather than passive slides, and short modules that fit busy schedules. Track completion and phishing results to find gaps. Update content each year to reflect current threats. NIST SP 800-50 Rev. 1 sets out how to build a security and privacy learning programme.

Mapping to Security Frameworks

• ISO 27001:2022: A.6.3 (Information security awareness, education and training)
• NIST CSF 2.0: PR.AT-01, PR.AT-02 (general awareness and training; role-based training)
• SOC 2: CC1.4 (Commitment to competence), CC2.2 (Internal communication of policies)

10. Encryption and Data Protection Policy

An Encryption and Data Protection Policy sets the technical standards for protecting sensitive information. It mandates encryption for data at rest and in transit, so that even if data is stolen it stays unreadable.

This policy supports GDPR and HIPAA, which both require strong data protection. If you also handle California privacy law, our CCPA compliance checklist covers those requirements. A healthcare provider encrypts patient records at rest with AES-256 and transmits them to a partner laboratory over TLS. Our free Data Management Policy generator covers encryption standards and data protection.

Sample Policy Clauses

• 10.1 Data at rest: Company laptops and portable media use full-disk encryption. Production databases holding Confidential or Restricted data use transparent data encryption.
• 10.2 Data in transit: Sensitive data sent over public networks uses TLS 1.2 as a minimum, with TLS 1.3 preferred and strong cipher suites.
• 10.3 Key management: Cryptographic keys are handled through the central key management system, and rotated at least annually or on compromise.
• 10.4 Cryptographic inventory and post-quantum planning: The company keeps a cryptographic inventory and plans post-quantum migration in line with the NCSC milestones (2028, 2031 and 2035), tracking the first post-quantum standards, NIST FIPS 203, 204 and 205 (published August 2024).

Customisation and Implementation Tips

Identify the systems that handle sensitive data to find where encryption matters most. Mandate strong algorithms such as AES-256 and secure protocols. Use central key management for the full key lifecycle, keep encrypted backups, and test key recovery.

Mapping to Security Frameworks

• ISO 27001:2022: A.8.24 (Use of cryptography)
• NIST CSF 2.0: PR.DS-01, PR.DS-02 (data at rest protected; data in transit protected)
• SOC 2: CC6.1 (Logical and physical access controls), CC6.7 (Transmission and movement of information)

11. AI Acceptable Use Policy

An AI Acceptable Use Policy states which AI tools staff may use and what data can go into them. It covers generative AI chat tools, coding assistants, AI features inside existing SaaS, and AI agents or connectors that can read or act on company systems. The policy keeps company data out of tools that could train on it or leak it, and holds people accountable for AI output.

The policy sits alongside the Data Classification Policy: what staff can put into a tool depends on the classification of the data. Approved tools run on company single sign-on accounts, not personal ones. Where AI output reaches customers, staff disclose it as required. Our free Responsible AI Policy generator builds a first version you can adapt.

Sample Policy Clauses

• 11.1 Approved tools: Staff use AI tools from the approved list. New tools go through a request and security-review process before use.
• 11.2 Data handling: Confidential and Restricted data go only into approved AI tools on company accounts. Public and Internal data follow the Data Classification Policy.
• 11.3 Human review: A person reviews AI output before it is used in a decision, shared with a customer or committed to production, and remains accountable for it.
• 11.4 Agents and integrations: AI agents and connectors get a security review and least-privilege scopes, and their actions are logged.

Customisation and Implementation Tips

Check vendor terms on training with customer data and on retention before you approve a tool. Start with a short approved list and expand it as reviews complete. Log what agents do so you can trace actions later.

Mapping to Security Frameworks

• ISO 27001:2022: A.5.10 (Acceptable use), A.5.23 (Information security for cloud services), A.8.12 (Data leakage prevention)
• NIST CSF 2.0: GV.PO-01, GV.SC-07 (organisational cybersecurity policy; supplier risk management)
• SOC 2: CC2.2 (Internal communication of policies), CC9.2 (Vendor and business partner risk)

Organisations that need a full AI management framework can look at ISO/IEC 42001:2023 and the NIST AI RMF 1.0, and those in scope of the EU AI Act should meet the Article 4 AI-literacy duty noted above.

12. Clean Desk and Clear Screen Policy

A Clean Desk and Clear Screen Policy protects information on paper, screens and devices, at the desk and at home. It reduces the chance that a passer-by, a visitor or a housemate sees something they should not.

The policy is simple to write and easy to check, which makes it a good candidate for early adoption. It applies to the office, home working and shared spaces such as cafes and co-working desks.

Sample Policy Clauses

• 12.1 Clear screen: Screens are locked whenever they are unattended, and lock automatically after at most five minutes of inactivity.
• 12.2 Clear desk: Confidential and Restricted paper is locked away when unattended and shredded when no longer needed.
• 12.3 Printing and whiteboards: Printouts are collected immediately, and whiteboards are wiped after meetings.
• 12.4 Home and shared spaces: The same rules apply at home and in shared spaces, including checking what is visible before sharing a screen on a call.

Customisation and Implementation Tips

Set the auto-lock timeout centrally through device management. Provide lockable storage and shredders. Remind staff about screen sharing on video calls, where a stray notification or open document can expose data.

Mapping to Security Frameworks

• ISO 27001:2022: A.7.7 (Clear desk and clear screen)
• NIST CSF 2.0: PR.AA-06, PR.AT-01 (physical access managed; awareness and training)
• SOC 2: CC6.4 (Restricting physical access to facilities and assets)

Framework mapping: ISO 27001:2022, NIST CSF 2.0 and SOC 2

The table below maps all 12 policies, plus the top-level information security policy, to ISO/IEC 27001:2022 Annex A, NIST CSF 2.0 and the SOC 2 Trust Services Criteria.

The mappings are indicative; the auditor and the organisation’s Statement of Applicability decide the final mapping.

Putting the policies to work

A policy only reduces risk once people follow it. Communicate each policy and train staff on the parts that apply to them, at onboarding and on a regular cycle. Build the rules into the tools and workflows where the work happens, so the Access Control Policy runs through your identity platform and the clear-screen rule comes from device management rather than a reminder email.

Enforce policies consistently, so the rules apply to everyone and non-compliance has predictable consequences. Review every policy at least annually and after any significant change to your systems, your risk profile or the standards you map to.

Customer security questionnaires ask which of these policies you hold and what is in them. Store the approved policies in one knowledge base and draw questionnaire answers from the current version, so your answers stay consistent with what you actually do. That is the workflow ResponseHub is built around: keep the source policies current, and let the answers follow.

Ready to put these policies into practice? Our free policy generator creates customised security policies in minutes, including an Information Security Policy, Access Control Policy, Incident Response Plan and a Responsible AI Policy.

Frequently asked questions

What are examples of information security policies?

Common examples are data classification, access control, password and authentication, incident response, acceptable use, BYOD, remote work, third-party and vendor security, security awareness and training, encryption and data protection, AI acceptable use, and clean desk and clear screen. They usually sit under one top-level information security policy.

What are the three types of information security policy?

NIST SP 800-12 Rev. 1 describes three: program policy, which sets the overall direction; issue-specific policy, which covers a topic such as acceptable use or remote work; and system-specific policy, which sets rules for a particular system. Most named policies are issue-specific.

What should an information security policy include?

ISO 27001:2022 clause 5.2 expects a top-level policy that suits the organisation, states security objectives or a framework for setting them, commits to meeting requirements and to continual improvement, and is documented, communicated and available. Topic-specific policies then add rules, responsibilities and review dates.

Which policies do you need for ISO 27001 and SOC 2?

ISO 27001 requires the clause 5.2 information security policy plus the topic-specific policies that your risk assessment and Statement of Applicability call for. SOC 2 has no fixed list; the auditor tests the controls you describe, so you need policies that back the criteria in your report.

How often should information security policies be reviewed?

Review each policy at least once a year, and again after any significant change, such as a new system, a merger, an incident or a move to a new version of a framework. Record the review date and the approver so you can show the policy is current.

What’s the difference between a policy, a standard and a procedure?

A policy states what you require and why. A standard sets the specific, measurable rule, such as a minimum password length or TLS version. A procedure gives the step-by-step instructions for carrying it out. The three work together: the policy sets intent, the standard sets the bar, and the procedure shows the way.