Documented Operating Procedures Policy

1. Purpose

The Documented Operating Procedures Policy establishes requirements for creating, maintaining, approving, communicating, and controlling documented operating procedures that support the organization’s information-security and business operations.

The objective is to ensure that important operational activities are performed:

Consistently
Securely
By authorized personnel
According to defined requirements
Using approved procedures
With appropriate evidence
With controlled changes
In a repeatable and auditable manner

Core Principle

Identify → Document → Approve → Communicate → Operate → Evidence → Review → Improve

2. Scope

This policy applies to documented operating procedures that support:

Information-security operations
IT operations
Cloud operations
Application operations
Infrastructure
Access management
Security monitoring
Incident management
Backup and recovery
Business continuity
Vulnerability management
Change management
Supplier management
Data protection
Privacy
Security testing
Compliance activities
Other business processes where documented procedures are required

It applies to:

Employees
Contractors
Consultants
Temporary personnel
Relevant third parties

3. Policy Statement

The organization shall maintain documented operating procedures for activities where documented instructions are necessary to ensure the secure, consistent, and controlled operation of information-processing and business activities.

Procedures shall be:

Appropriate to the organization’s size and complexity
Based on business and security risks
Clear and understandable
Assigned to an owner
Approved before use
Accessible to authorized personnel
Protected against unauthorized modification
Reviewed periodically
Updated when significant changes occur
Retained according to applicable requirements

4. Objectives

The organization shall use documented operating procedures to:

Establish consistent operating practices.
Reduce dependency on individual knowledge.
Support secure execution of critical activities.
Reduce operational errors.
Support employee and contractor training.
Preserve operational knowledge.
Support business continuity.
Provide evidence of controlled operations.
Support internal and external audits.
Enable continual improvement.

5. Procedure Identification

The organization shall determine which operational activities require documented procedures.

Consider:

Information-security risk
Business criticality
Complexity
Frequency
Personnel dependency
Regulatory requirements
Customer requirements
Contractual requirements
Technical complexity
Potential security impact
Potential business impact
Requirement for repeatability

Examples

Documented procedures may be required for:

User onboarding
User termination
Privileged access
Backup
Restore
Security monitoring
Incident response
Vulnerability management
Patch management
Cloud configuration
Change management
Security testing
Supplier onboarding
Supplier offboarding
Data deletion
Disaster recovery

6. Procedure Hierarchy

The organization may use the following document hierarchy:

Level	Document	Purpose
1	Policy	Defines management direction and mandatory principles
2	Standard	Defines required security or technical requirements
3	Procedure	Defines how an activity is performed
4	Work Instruction	Provides detailed operational steps
5	Form / Checklist	Captures execution evidence
6	Record	Demonstrates that an activity occurred

Example

Access Control Policy

↓

Access Management Standard

↓

User Access Provisioning Procedure

↓

AWS User Provisioning Work Instruction

↓

Access Request Form

↓

Access Approval Record

7. Procedure Owner

Every controlled procedure shall have an assigned owner.

The owner is responsible for:

Maintaining the procedure
Ensuring accuracy
Coordinating updates
Reviewing effectiveness
Identifying required changes
Ensuring appropriate approval
Removing obsolete versions

Procedure Owner

Name/Role: ______________________________

Department: _____________________________

8. Procedure Information

Every controlled procedure should contain appropriate document-control information.

Field	Requirement
Procedure Name	Required
Document ID	Required
Version	Required
Owner	Required
Approver	Required
Effective Date	Required
Review Date	Required
Classification	As applicable
Status	Required

9. Minimum Procedure Content

Where applicable, an operating procedure should define:

Purpose
Scope
Roles and responsibilities
Preconditions
Required inputs
Required tools/systems
Operating steps
Security requirements
Approval requirements
Exceptions
Evidence/records
Escalation requirements
Outputs
Related documents
Review requirements

The level of detail should be proportionate to the complexity and risk of the activity.

10. Procedure Development

When creating a procedure:

☐ Business requirement identified
☐ Security requirements identified
☐ Applicable risks identified
☐ Process owner identified
☐ Roles identified
☐ Inputs identified
☐ Process steps documented
☐ Security controls identified
☐ Required evidence identified
☐ Exceptions considered
☐ Escalation defined
☐ Related documents identified
☐ Reviewer identified
☐ Approver identified

11. Procedure Approval

Procedures shall be approved by an authorized person before being placed into operational use.

Approval should consider:

Accuracy
Security
Operational practicality
Compliance requirements
Risk
Dependencies
Resource requirements

Approval

Prepared By: ____________________________

Reviewed By: ____________________________

Approved By: ____________________________

Approval Date: ___________________________

12. Procedure Version Control

Each controlled procedure shall have a unique version.

Example:

Version 1.0 — Initial release
Version 1.1 — Minor correction
Version 2.0 — Significant process change

Changes shall be documented appropriately.

Version	Date	Change	Author	Approver

13. Change Management

Procedures shall be reviewed when changes occur that may affect the process.

Triggers include:

☐ New technology
☐ New system
☐ New cloud service
☐ Security incident
☐ Audit finding
☐ Regulatory change
☐ Customer requirement change
☐ Organizational change
☐ Process change
☐ New security risk
☐ Supplier change
☐ Business continuity event
☐ Control change

14. Periodic Review

Each controlled procedure shall be reviewed at an appropriate frequency.

The review should determine whether:

The procedure remains accurate
The process remains applicable
Security requirements remain current
Technology has changed
Responsibilities remain correct
Evidence requirements remain appropriate
Regulatory requirements have changed
Previous findings have been addressed

Review Frequency

Default: ______________________________

Review Record

Review Date	Reviewer	Result	Changes Required	Next Review

15. Procedure Status

Controlled procedures may have the following statuses:

☐ Draft
☐ Under Review
☐ Approved
☐ Effective
☐ Suspended
☐ Under Revision
☐ Retired
☐ Obsolete

Only approved and effective procedures shall be used for normal operations.

16. Procedure Accessibility

Personnel shall have access to the current version of procedures relevant to their responsibilities.

Access may be provided through:

ISMS portal
Document management system
Knowledge base
Internal wiki
Security platform
Approved shared repository

Access shall be controlled where procedures contain sensitive information.

17. Obsolete Procedures

When a procedure is replaced:

☐ Previous version identified
☐ Current version published
☐ Previous operational copy removed where appropriate
☐ Obsolete version marked clearly
☐ Historical record retained where required
☐ Personnel informed where necessary

Obsolete procedures shall not remain available in a way that could reasonably cause personnel to follow an outdated process.

18. Operational Use

Personnel shall perform activities according to applicable approved procedures.

Where an activity cannot be performed as documented:

☐ Escalate to process owner
☐ Assess security impact
☐ Record deviation where required
☐ Apply approved exception process
☐ Update procedure if necessary

Personnel should not create informal workarounds that bypass established security controls without appropriate authorization.

19. Roles and Responsibilities

Role	Responsibility
Management	Establishes direction and resources
Procedure Owner	Maintains procedure
Process Owner	Ensures operational implementation
Information Security	Reviews security requirements
IT / Engineering	Implements technical procedures
Compliance	Monitors compliance where applicable
Personnel	Follow applicable procedures
Internal Audit	Independently assesses implementation where applicable

20. Separation of Duties

Where appropriate, procedures shall incorporate segregation of duties.

Examples:

Requester vs approver
Developer vs production approver
Administrator vs reviewer
Backup operator vs restore approver
Security tester vs system owner

Segregation should be based on risk and business requirements.

21. Security Requirements Within Procedures

Operating procedures should identify applicable security requirements.

Examples:

Authentication
MFA
Least privilege
Authorization
Encryption
Logging
Monitoring
Backup
Change control
Data classification
Secure disposal
Evidence preservation

Security requirements should be incorporated into operational steps rather than treated as separate optional activities.

22. Evidence and Records

Procedures shall identify what evidence should be generated during execution.

Examples:

Access requests
Approval records
Change tickets
Backup logs
Restore test results
Vulnerability reports
Incident records
Security alerts
Monitoring records
Review checklists
Configuration records

Evidence Requirement

23. Records Management

Operational records shall be:

Accurate
Protected
Accessible to authorized personnel
Traceable to the activity
Retained for the defined period
Securely disposed of when no longer required

Record Retention

Retention Period: ________________________

Storage Location: ________________________

Record Owner: ___________________________

24. Emergency Procedures

Critical operational processes should include emergency instructions where appropriate.

Examples:

Emergency access
Emergency change
Security incident
Disaster recovery
Service outage
Cloud compromise
Critical vulnerability

Emergency procedures should define:

Trigger
Authorized personnel
Required actions
Escalation
Communication
Evidence
Post-event review

25. Business Continuity

Critical operating procedures should consider business continuity.

Where applicable:

☐ Alternate personnel identified
☐ Backup procedure available
☐ Emergency contacts identified
☐ Critical dependencies documented
☐ Recovery procedure available
☐ Manual workaround documented
☐ Procedure tested
☐ Lessons learned incorporated

26. Third-Party Procedures

Where operational activities are performed by suppliers:

☐ Supplier responsibilities documented
☐ Security requirements defined
☐ Procedures coordinated
☐ Escalation defined
☐ Evidence requirements defined
☐ Incident requirements defined
☐ Change notification defined
☐ Business continuity requirements defined

27. Cloud Operations

For cloud environments, procedures should address applicable activities such as:

IAM
MFA
Privileged access
Configuration
Logging
Monitoring
Backup
Recovery
Network security
Vulnerability management
Secrets management
Incident response
Change management

AWS SaaS Example

A startup operating on AWS may maintain procedures for:

AWS account onboarding
IAM user/role provisioning
Privileged access
Cloud configuration
Security logging
Backup
Restore
Security incident response
Production deployment
Emergency access

28. Application Operations

Where applicable, procedures should cover:

☐ Development
☐ Code review
☐ Testing
☐ Security testing
☐ Release approval
☐ Production deployment
☐ Rollback
☐ Vulnerability management
☐ Dependency management
☐ Secrets management
☐ Emergency changes

29. Procedure Training

Personnel shall receive appropriate instruction where a procedure is:

New
Significantly changed
Critical to security
Complex
Role-specific
Required by regulation/customer contract

Training may include:

☐ Demonstration
☐ Workshop
☐ Security awareness
☐ Role-based training
☐ Work instruction
☐ Knowledge assessment
☐ Practical exercise

30. Procedure Acknowledgement

Where required, personnel may be required to acknowledge:

☐ Procedure received
☐ Procedure reviewed
☐ Training completed
☐ Responsibilities understood

Acknowledgement should not be treated as evidence that the procedure is actually being followed.

Operational compliance should be independently verified where appropriate.

31. Procedure Compliance Monitoring

The organization should periodically verify that procedures are being followed.

Methods may include:

Sampling
Internal audit
Control testing
Compliance review
System monitoring
Management review
Process observation
Evidence review

Compliance Result

32. Procedure Effectiveness

Assess whether the procedure is achieving its intended outcome.

Consider:

Security incidents
Operational errors
Audit findings
Process failures
Exceptions
Delays
Rework
User feedback
Control effectiveness

Effectiveness Assessment

33. Exceptions and Deviations

Where personnel cannot follow an approved procedure:

☐ Deviation identified
☐ Business reason documented
☐ Security impact assessed
☐ Exception raised where required
☐ Compensating control implemented
☐ Approval obtained
☐ Deviation monitored
☐ Procedure updated if necessary

34. Procedure Findings

Record identified weaknesses.

Finding ID	Procedure	Requirement	Finding	Risk	Action	Owner	Due Date

35. Corrective Action

For significant procedure weaknesses:

Action ID	Finding	Root Cause	Corrective Action	Owner	Due Date	Evidence	Status

Corrective action should address the underlying process weakness rather than simply updating documentation.

36. Procedure Review Register

Maintain a register of controlled procedures.

Procedure ID	Procedure	Owner	Version	Effective Date	Review Date	Status

37. Procedure Criticality

Classify procedures according to their operational importance.

Critical

Failure could significantly affect:

Customer services
Production systems
Security
Confidential information
Business continuity
Regulatory obligations

Important

Failure could create moderate operational or security impact.

Standard

Failure has limited impact and can generally be recovered quickly.

Classification

Procedure Criticality: ______________________

38. Critical Procedure Controls

For critical procedures:

☐ Owner assigned
☐ Backup owner assigned
☐ Current version available
☐ Staff trained
☐ Emergency instructions available
☐ Dependencies documented
☐ Evidence defined
☐ Procedure tested
☐ Business continuity considered
☐ Periodic review performed

39. Procedure Dependencies

Document systems, suppliers, personnel, and other procedures required to execute the process.

Dependency	Type	Owner	Criticality	Alternative

40. Procedure Change Record

Change ID	Procedure	Change	Reason	Security Impact	Approved By	Date

41. Document Security

Procedures containing sensitive information shall be protected appropriately.

Examples:

Architecture details
Security configurations
Administrative procedures
Incident response procedures
Recovery procedures
Security testing instructions
Emergency access procedures

Controls may include:

☐ Access restrictions
☐ Version control
☐ Audit logging
☐ Encryption
☐ Controlled distribution
☐ Secure storage

42. Management Review

Management should receive information about significant operational procedure issues where relevant.

Examples:

Critical procedures without owners
Overdue reviews
Repeated procedure deviations
Critical operational failures
Significant audit findings
Security incidents caused by procedural weaknesses
Major changes requiring procedure updates

Management Review Input

43. Continual Improvement

Procedures shall be improved when evidence indicates that changes are necessary.

Inputs may include:

Audit findings
Security incidents
Near misses
Lessons learned
Technology changes
User feedback
Risk assessments
Control testing
Customer requirements
Regulatory changes

Improvement Action

44. AWS SaaS Startup Example

Scenario

A SaaS startup operates its production application in AWS.

The organization maintains the following operating procedures:

Procedure	Purpose
AWS Access Management	Provision and remove cloud access
Production Deployment	Secure production releases
Backup & Restore	Protect and recover customer data
Vulnerability Management	Identify and remediate vulnerabilities
Security Monitoring	Monitor security events
Incident Response	Respond to security incidents
Emergency Access	Manage exceptional administrative access
Supplier Security Review	Assess critical suppliers

Example

For Production Deployment, the procedure may require:

Change request created.
Developer completes testing.
Code review completed.
Security checks completed where required.
Production approval obtained.
Deployment performed.
Deployment recorded.
Monitoring performed.
Rollback initiated if required.

Evidence

Change ticket
Code review
CI/CD record
Approval
Deployment log
Monitoring evidence

Audit Trail

Approved Procedure → Authorized User → Required Steps → Security Controls → Operational Evidence → Review → Improvement

45. Startup-Friendly Model

A startup should not create hundreds of procedures simply to satisfy an audit.

Start with procedures for activities that are:

High Risk

Production access
Privileged access
Incident response
Backup and recovery
Security monitoring
Vulnerability management
Production deployment

High Frequency

User onboarding
Access provisioning
Access removal
Change management
Security alert handling

High Dependency

AWS operations
SaaS providers
Payment systems
Critical suppliers

High Compliance Impact

Customer data handling
Privacy
Security incidents
Data retention
Contractual requirements

46. Common Mistakes

Avoid:

Creating procedures nobody follows
Writing procedures only for audit purposes
Making procedures unnecessarily complex
Failing to assign an owner
Allowing outdated versions to remain in use
Failing to define evidence
Failing to update procedures after technology changes
Creating procedures without considering actual workflows
Ignoring emergency scenarios
Failing to train relevant personnel
Treating acknowledgement as proof of compliance
Failing to test critical procedures
Not documenting deviations
Maintaining duplicate or conflicting procedures

47. Relationship With Other ISMS Documents

Document	Relationship
Information Security Policy	Establishes overall security direction
Security Standards	Define mandatory security requirements
Risk Assessment	Identifies risks requiring operational controls
Statement of Applicability	Records applicable controls
Document Control Procedure	Controls document lifecycle
Policy Management Procedure	Controls policy lifecycle
Security Compliance Checklist	Assesses compliance
Access Management Procedure	Implements access controls
Change Management Procedure	Controls operational changes
Incident Response Procedure	Defines incident operations
Backup & Restore Procedure	Defines recovery operations
Business Continuity Plan	Supports continuity
Supplier Management Procedure	Controls supplier activities
Internal Audit Procedure	Independently evaluates processes
Corrective Action Tracker	Tracks process improvements

48. ISO/IEC 27001 Connection

Documented operating procedures support the organization’s ability to consistently perform information-security and operational activities in accordance with its ISMS requirements.

The organization should determine which procedures are necessary based on:

ISMS scope
Information-security risks
Business processes
Applicable controls
Legal and regulatory requirements
Customer requirements
Contractual obligations
Technology
Operational complexity
Business continuity requirements

A Documented Operating Procedures Policy is not itself a universally prescribed ISO/IEC 27001 form or mandatory document title.

ISO/IEC 27001 does not require an organization to document every operational activity. Documentation should be proportionate to the organization’s needs and risk. The organization should retain appropriate documented information and evidence necessary to demonstrate that relevant processes and controls are operating as intended.

49. Audit Evidence Checklist

For sampled operating procedures, the organization should be able to demonstrate:

☐ Procedure identified
☐ Business/security need established
☐ Owner assigned
☐ Current version available
☐ Approval recorded
☐ Effective date recorded
☐ Relevant personnel have access
☐ Relevant personnel trained where required
☐ Procedure actually used
☐ Operational evidence exists
☐ Changes controlled
☐ Periodic review completed
☐ Deviations managed
☐ Findings tracked
☐ Corrective actions completed where required

50. Final Operating Procedure Audit Trail

For every significant operational activity, the organization should be able to demonstrate:

What activity needs to be performed?
Why does it require a documented procedure?
Who owns the procedure?
Who is authorized to perform it?
What steps must be followed?
What security controls apply?
What evidence is generated?
How is the procedure kept current?
What happens when the procedure cannot be followed?
How is effectiveness verified?
How are lessons learned incorporated?

Final Principle

Documented operating procedures should not exist simply to satisfy an audit. They should provide clear, repeatable, secure instructions for performing important activities and create reliable evidence that the organization’s security controls are operating in practice.