Comparing Policies, Rules, Standards, and Guidelines

A useful structure is to set direction in policy, assign responsibilities and obligations in internal rules, specify compliance conditions in standards, and describe execution in procedures. Guidelines support understanding and judgment; records show what happened.

This is the practical convention used in this category. Names and hierarchies vary between organizations and external bodies. “Security policy” may mean the top-level policy or the whole collection of rules and standards.

Document roles

Document	Question answered	Content and wording example	Treatment here	Example approver
Policy	Why protect information, and what matters?	Leadership commitments: “We provide necessary resources”	Organization-wide principles	Leadership / board or equivalent
Internal rules	Who must do what?	Duties and approvals: “Approval is required”	Mandatory internal rules	Authorized decision-maker
Standard	What constitutes compliance?	Scope, settings, deadlines, verification: “Apply MFA to services in scope”	Mandatory requirements within scope	Delegated responsible authority
Guideline	How should people exercise judgment?	Recommendations and examples: “Enter recipients after checking the message”	Generally supporting guidance	Document owner
Procedure / manual	How is the task performed?	Actions, checks, failure handling: “Enter the request number”	Execution instructions for the task	Operations owner
Record	What actually happened?	Request, approval, execution, result, correction	Evidence subject to retention and access rules	Reviewer appropriate to the record

A document called a guideline can still be binding through law, contract, or internal rules. Names and wording alone do not establish authority. Here, mandatory requirements are grounded in rules or standards and referenced from guidelines.

Relationships

Policy — Business purpose and principles
  └ Internal rules — Responsibilities, obligations, approval arrangements
      └ Standards — Specific compliance conditions
          └ Procedures — Execution and verification
              └ Records — Results and evidence

Guidelines — Support understanding and judgment across these documents

Guidelines do not have to sit between standards and procedures. Do not weaken a higher-level obligation by changing a lower-level document alone; resolve contradictions with the higher-level owner.

Expressing the same topic in different documents

The same control needs different content at each level. First identify whether the sentence expresses purpose, responsibility and obligation, compliance conditions, judgment support, execution, or actual results.

The following five examples describe a fictional organization. Numbers, intervals, and deadlines illustrate drafting and must be adapted to your risks and requirements. They do not imply creating five separate top-level policies: each table compares content that could appear in shared documents.

1. Access management

Document	Example
Policy	Provide information to authorized people within business needs and prevent improper use.
Rules	The information owner approves access grants and changes. IT implements approved access and adjusts or removes it for transfers and departures.
Standard	Customer information systems use individually attributable IDs and MFA. Review access quarterly; disable departing staff access by the departure time.
Guideline	Consider whether viewing, editing, and exporting are each necessary; do not rely on job title alone.
Procedure	Verify the request and approval, configure the specified access, and attach test results and configuration history.
Record	Save the request number, ID, permissions, approver, operator, date/time, and verification result.

Distinction: Rules identify who approves access; standards specify which systems require MFA and when access is reviewed; procedures describe checking approval and configuring access. Guidelines support the choice of permissions.

Document	Example
Policy	Protect information according to sensitivity while enabling necessary sharing.
Rules	People sharing confidential information externally obtain information-owner approval. The owner checks necessity and recipients; the person sharing uses an approved method.
Standard	Use an approved service that restricts access to named recipients. Do not use anonymously accessible links. Sharing expires within 30 days; continued sharing requires renewed approval.
Guideline	Consider sharing only the fields the recipient needs rather than the entire file. Check whether contract numbers or context identify a person even after names are removed.
Procedure	Check the request and approval, configure files, recipients, and expiry, verify the scope against approval, notify recipients, and verify access ends after expiry.
Record	Save the information shared, purpose, recipients, approver, method, configured expiry, and verification of sharing and termination.

Distinction: Approval obligations belong in rules; restrictions on anonymous links and a 30-day expiry belong in standards. Screen instructions for configuring recipients and expiry belong in procedures. Minimizing shared content is a recommendation here; place it in rules or standards if it must be mandatory.

3. Introducing a cloud service

Document	Example
Policy	Understand and manage risks and responsibilities associated with external services.
Rules	The requesting department submits an assessment before introduction. Security staff evaluate it and a designated decision-maker approves use. Significant changes in purpose or information require reassessment.
Standard	Services storing confidential information must support organizational account management, MFA, recipient-restricted sharing, activity logs, and data export/deletion at termination.
Guideline	Check that required management capabilities are available in the actual contractual plan, not just advertised feature lists. Explain, with a rules reference, that assessment is required before entering work data even during a free trial.
Procedure	Enter purpose, classification, and plan in the request. Review terms and settings, send findings for approval, verify initial configuration after approval, and register the service in the approved list.
Record	Save the request, date terms were checked, assessment, approver, conditions of use, configuration verification, and next assessment date.

Distinction: Rules define assessment and approval authority; standards define adoption criteria; procedures describe preparing and routing the assessment. Guidelines explain commonly overlooked details and existing obligations.

4. Backup and recovery

Document	Example
Policy	Prepare to restore important information and operations after incidents or failures to support continuity.
Rules	Business owners establish recovery objectives; IT implements backup and recovery that meet them. Perform restoration tests and report deficiencies and corrective plans to business owners.
Standard	The order service meets a four-hour recovery time objective (RTO) and one-hour recovery point objective (RPO). Separate backup authentication and deletion permissions from production; verify elapsed time and restored data in quarterly tests.
Guideline	Include unavailable authentication, networks, and connected services when selecting test scenarios. Do not infer recoverability from successful backup jobs alone.
Procedure	Prepare the approved isolated environment, select recovery data, restore, check integrity and order-processing functions, measure time until business use is possible, and report results.
Record	Save the recovery data timestamp, restored scope, start/completion times, data-loss window, functional results, deficiencies, and corrective owners/deadlines.

Distinction: Rules assign responsibility for objectives and recovery; standards specify required recovery time and data-loss limits; procedures give restoration and verification steps. Records contain measured results and whether objectives were met.

5. Incident reporting and initial response

Document	Example
Policy	Detect incidents and suspicions early, limit impact, restore operations, and prevent recurrence.
Rules	People report incidents or suspicions immediately to the designated contact. The response owner directs initial response and escalates major incidents to leadership. Define authority for service suspension and external notification.
Standard	Classify suspected customer-data exposure, misuse of privileged accounts, and complete interruption of important operations as major events. Contact the response owner within 15 minutes of receiving a major-event report; contact the deputy if the owner is unreachable.
Guideline	Report known facts before cause or impact is confirmed. For example, give the time and content of suspicious sign-in notifications and avoid deleting records independently. Reference reporting obligations and relevant procedures.
Procedure	Contact the designated channel with discovery time, target, and circumstances. Intake staff create a report and contact the response owner using classification criteria. Authorized responders follow instructions to limit impact and preserve logs.
Record	Maintain a timeline of discovery, receipt, escalation, and initial response, including report content, classification, decision-makers, instructions, actions, evidence locations, and results.

Distinction: Rules define reporting duties and command/decision authority; standards define major-event criteria and escalation deadlines; procedures specify contacts, intake, and preservation tasks. Guidelines explain how to report confidently without independently changing obligations or deadlines.

Choosing where a sentence belongs

“Review access quarterly” defines an interval and belongs in the standard. “The owner is responsible for reviewing access” assigns an obligation and belongs in rules. “Export the list and identify unnecessary permissions” is procedural; the reviewed list and corrective results are records.

Split sentences that combine obligations, numbers, and operating steps. Keep each deadline in one authoritative source, such as the standard, and reference it from procedures and guidelines to reduce inconsistencies during revision.

When to combine or separate documents

Separating document roles and separating files are different decisions. The examples show where content belongs, but all six types do not need independent files. Use this section to decide how to package and maintain that content.

Combine when scope and ownership are shared, especially in a small organization. Put common obligations in one rulebook and configuration requirements in controlled annexes.
Separate when revision frequency, audience, or disclosure differs. A public policy and internal logging or incident-response instructions usually have different audiences.
Reference existing documents for privacy, development, suppliers, and continuity. Identify relevant sections and responsibility boundaries rather than copying obligations.

For example, one management rulebook can contain responsibilities and obligations in its main text and specific standards in controlled annexes. Even within one file, distinguish mandatory requirements from recommendations and identify approval and revision arrangements for each part.

In Japanese, kitei written as 規程 can describe a rulebook, while 規定 refers to individual provisions. This category uses “internal rules” for formally approved requirements within an organization.

Checks before drafting

Does the document define principles, obligations, compliance conditions, recommendations, tasks, or evidence?
Are scope and mandatory status explicit?
Are higher-level authority and lower-level references identified?
Are ownership, approvals, and exceptions consistent?
Can changes be traced to affected documents, configurations, and training?

Information Security Management Rules
Creating, Approving, and Reviewing Documents
IPA: Information Security Guidelines for SMEs — Policy, rules, and handbook samples, in Japanese.