1. Purpose

This Operating Procedure defines the standardized method for performing a specific business, information-security, technology, compliance, or operational activity.

The procedure should explain who performs the activity, what is performed, how it is performed, when it is performed, what evidence is generated, and how exceptions are handled.

Core Principle

Define → Assign → Perform → Record → Verify → Review → Improve

---

2. Procedure Information

Field	Details
Procedure Title
Procedure ID
Procedure Owner
Process Owner
Department
Version
Effective Date
Review Date
Classification
Status	Draft / Approved / Retired
Related Policy
Related Standard
Related Risk
Approved By

---

3. Scope

This procedure applies to:

• People
• Processes
• Systems
• Applications
• Infrastructure
• Information
• Third parties

Included

Excluded

Applicability

---

4. Objective

The objectives of this procedure are to:

• Establish a consistent operating process
• Define responsibilities
• Reduce operational and security risk
• Ensure required controls are performed
• Generate appropriate evidence
• Support compliance requirements
• Enable monitoring and review
• Reduce dependency on individual knowledge

---

5. Preconditions

Before starting the procedure, verify that:

☐ Required approval exists
☐ Required access is available
☐ Required information is available
☐ Required systems are available
☐ Required personnel are assigned
☐ Relevant policies are understood
☐ Security requirements are identified
☐ Dependencies are available
☐ Required tools are available

---

6. Roles and Responsibilities

Role	Responsibility
Procedure Owner
Process Owner
Performer
Reviewer
Approver
Security/Compliance
System Owner
Third Party

---

7. Required Inputs

Identify information, approvals, systems, or documents required to perform the procedure.

Input	Source	Owner	Required?

---

8. Required Tools and Systems

Tool/System	Purpose	Owner	Access Required

Examples may include:

• AWS
• Microsoft 365
• GitHub
• Jira
• SIEM
• Ticketing system
• HR system
• GRC platform
• Vulnerability scanner
• Backup platform

---

9. Procedure Steps

Document the actual operational process.

Step	Activity	Responsible	Input	Output/Evidence
1
2
3
4
5

Step 1

Activity:

Responsible:

Method:

Expected Result:

Evidence:

Step 2

Activity:

Responsible:

Method:

Expected Result:

Evidence:

Step 3

Activity:

Responsible:

Method:

Expected Result:

Evidence:

---

10. Security Requirements

The procedure must address applicable security requirements.

☐ Authentication
☐ MFA
☐ Least privilege
☐ Segregation of duties
☐ Confidentiality
☐ Integrity
☐ Availability
☐ Encryption
☐ Logging
☐ Monitoring
☐ Secure information handling
☐ Access restrictions
☐ Data retention
☐ Secure disposal

Additional Security Requirements

---

11. Information Handling

Identify information used or generated during the procedure.

Information	Classification	Handling Requirement	Storage	Retention

Do not collect or retain information that is unnecessary for the activity.

---

12. Access Requirements

Document the minimum access required.

System	Role	Permission	Justification	Approval

Access should follow:

Need → Authorization → Least Privilege → Authentication → Monitoring → Review

---

13. Verification and Quality Check

After completing the activity, verify that the expected result has been achieved.

☐ Activity completed
☐ Required control performed
☐ Output reviewed
☐ Evidence generated
☐ Errors identified and addressed
☐ Required approval obtained
☐ Records updated

Verification Method

Reviewer

Verification Evidence

---

14. Evidence and Records

Identify the records generated by the procedure.

Record/Evidence	Owner	Storage Location	Retention

Examples:

• Tickets
• Approval records
• System logs
• Screenshots
• Reports
• Review records
• Access records
• Change records
• Scan reports
• Meeting records
• System-generated evidence

Evidence should be protected from unauthorized modification or deletion.

---

15. Exceptions and Deviations

If the procedure cannot be performed as defined:

1. Record the deviation.
2. Identify the reason.
3. Assess the associated risk.
4. Apply compensating controls where appropriate.
5. Obtain required approval.
6. Record the exception.
7. Define corrective action where necessary.

Exception Record

Exception	Reason	Risk	Compensating Control	Approval	Expiry

---

16. Failure Handling

If the procedure fails or produces an unexpected result:

☐ Stop the activity where necessary
☐ Protect affected information/assets
☐ Notify the responsible owner
☐ Record the issue
☐ Assess impact
☐ Escalate where required
☐ Correct the immediate problem
☐ Initiate incident management where applicable
☐ Initiate corrective action where required

Escalation Contact

---

17. Security Incident Handling

If a security incident is identified during execution:

Stop/Contain → Report → Investigate → Recover → Record → Improve

Do not attempt actions outside the individual’s authorized responsibility.

Incident Reporting Method

---

18. Change Management

Changes to this procedure or the underlying process should be evaluated before implementation.

Consider:

• Security impact
• Business impact
• Compliance impact
• System impact
• Information impact
• Access impact
• Third-party impact
• Training requirements
• Evidence requirements

Change Approval

Change	Impact	Owner	Approval	Date

---

19. Frequency

Define when the procedure must be performed.

☐ Continuous
☐ Daily
☐ Weekly
☐ Monthly
☐ Quarterly
☐ Semi-annually
☐ Annually
☐ Event-driven
☐ Other: __________

Trigger

---

20. Monitoring

Where appropriate, monitor whether the procedure is being performed effectively.

Metric	Target	Frequency	Owner

Examples:

• Completion rate
• Exception rate
• Error rate
• Overdue activities
• Failed activities
• Security incidents
• Control failures
• SLA compliance

---

21. Compliance Requirements

Identify requirements applicable to the procedure.

☐ ISO/IEC 27001
☐ Customer requirements
☐ Contractual requirements
☐ Privacy requirements
☐ Legal requirements
☐ Regulatory requirements
☐ Internal policy requirements
☐ Security requirements

Applicable Requirements

---

22. Control Mapping

Where the procedure supports an ISMS control, document the relationship.

Requirement/Control	Procedure Activity	Evidence

The procedure should support the organization’s applicable control requirements without treating the procedure itself as proof that the control is effective.

---

23. Training and Awareness

Determine whether personnel performing this procedure require training.

☐ Training required
☐ No specific training required
☐ Role-specific training
☐ Security awareness
☐ Technical training
☐ Refresher training

Training Requirement

Training Evidence

---

24. Third-Party Execution

If a third party performs part of the procedure:

☐ Third party identified
☐ Responsibilities defined
☐ Security requirements communicated
☐ Access controlled
☐ Confidentiality requirements addressed
☐ Evidence requirements defined
☐ Performance monitored
☐ Offboarding requirements defined

---

25. Business Continuity

If this procedure supports a critical business process, define what happens when the normal process or system is unavailable.

Primary Process

Alternative Process

Manual Workaround

Recovery Requirement

---

26. Review and Maintenance

The procedure owner should review this procedure based on:

• Defined review frequency
• Significant process changes
• Security incidents
• Audit findings
• Regulatory changes
• Technology changes
• Organizational changes
• Supplier changes
• Lessons learned

Review Record

Review Date	Reviewer	Changes Required	Result	Approval

---

27. Procedure Effectiveness

Determine whether the procedure achieves its intended objective.

Consider:

☐ Procedure is consistently followed
☐ Activities are completed on time
☐ Required evidence exists
☐ Errors are controlled
☐ Security requirements are met
☐ Exceptions are understood
☐ Findings are reducing
☐ Users understand the procedure
☐ Procedure remains practical
☐ Procedure supports business requirements

Effectiveness Assessment

---

28. Findings and Corrective Actions

Finding	Risk	Root Cause	Corrective Action	Owner	Due Date	Status

Corrective actions should be tracked until implementation and effectiveness are verified.

---

29. Document Control

Version History

Version	Date	Change	Author	Approved By
1.0		Initial version

Document Status

☐ Draft
☐ Under Review
☐ Approved
☐ Superseded
☐ Retired

---

30. Related Documents

Document	Relationship
Information Security Policy	Governing policy
Risk Assessment	Identifies relevant risks
Statement of Applicability	Identifies applicable controls
Work Instruction	Provides detailed task instructions
Checklist	Supports execution/verification
Record/Register	Provides evidence
Incident Procedure	Handles security incidents
Change Procedure	Controls changes
Business Continuity Plan	Addresses disruption
Supplier Procedure	Addresses third-party activities

---

31. Approval

Procedure Owner: __________________________

Process Owner: __________________________

Security/Compliance Reviewer: __________________________

Approver: __________________________

Approval Date: __________________________

Effective Date: __________________________

Next Review Date: __________________________

---

32. AWS SaaS Startup Example

Procedure

Title: AWS Production Access Procedure

Purpose

Define how employees and approved third parties receive, use, review, and revoke access to AWS production environments.

Preconditions

☐ Business need identified
☐ Manager approval obtained
☐ System owner approval obtained
☐ Security requirements reviewed
☐ MFA available

Process

Step	Activity	Responsible	Evidence
1	User submits access request	User	Access ticket
2	Business owner validates need	Manager	Approval
3	System owner validates permission	System Owner	Approval
4	IAM role assigned	Cloud Admin	IAM record
5	MFA verified	Security/IT	Authentication record
6	Access provided	Cloud Admin	Ticket
7	Access reviewed periodically	System Owner	Access review
8	Access removed when no longer required	Cloud Admin	Revocation evidence

Security Requirements

• Individual accounts
• MFA
• Least privilege
• No shared administrator accounts
• Privileged activity logging
• Temporary access where practical
• Periodic access review
• Immediate revocation when employment or business need ends

Evidence

• Access request
• Approval
• IAM configuration
• MFA status
• Access review
• Revocation record

---

33. Startup-Friendly Operating Procedure Model

A startup does not need a 30-page procedure for every activity.

For a simple activity, the minimum useful structure may be:

1. Purpose

Why the procedure exists.

2. Owner

Who is responsible.

3. Trigger

When it starts.

4. Steps

What people actually do.

5. Security Requirements

What must not be missed.

6. Evidence

What proves the activity happened.

7. Exceptions

What happens when the normal process cannot be followed.

8. Review

When the procedure is reassessed.

This keeps the ISMS practical rather than creating unnecessary documentation.

---

34. Common Mistakes

Avoid:

• Creating procedures that nobody follows.
• Writing procedures that are too theoretical.
• Failing to identify the process owner.
• Not defining the trigger.
• Not defining the actual steps.
• Failing to identify required evidence.
• Giving excessive access to perform the procedure.
• Ignoring exceptions.
• Failing to define escalation.
• Keeping obsolete procedures available as current documents.
• Not reviewing procedures after major changes.
• Creating duplicate procedures for the same activity.
• Treating a procedure document as proof that the activity actually occurred.
• Creating excessive documentation that does not add operational value.

---

35. Relationship With the ISMS

Operating procedures translate policies and control requirements into day-to-day activities.

A typical relationship is:

Business Requirement → Risk → Policy → Control → Procedure → Activity → Evidence → Review → Improvement

For example:

Risk: Unauthorized production access

Policy: Access must be authorized and appropriately restricted

Control: Access is limited according to business need

Procedure: AWS Production Access Procedure

Activity: Request → Approve → Grant → Monitor → Review → Revoke

Evidence: Access ticket, approval, IAM record, review record, revocation record

---

36. ISO/IEC 27001 Connection

Operating procedures can support the organization’s ISMS by translating applicable information-security requirements and controls into repeatable operational activities.

The exact procedures required should be determined based on:

• ISMS scope
• Risk assessment
• Risk treatment
• Statement of Applicability
• Applicable controls
• Business requirements
• Legal and regulatory requirements
• Customer requirements
• Contractual obligations
• Operational complexity

ISO/IEC 27001 does not require an organization to create an identically named “Operating Procedure Template” for every activity.

The objective is to maintain the documented information necessary to support controlled operation and provide appropriate evidence of activities performed.

---

37. Audit Evidence Checklist

For an auditor, the organization should be able to demonstrate:

☐ Approved procedure
☐ Current version
☐ Defined owner
☐ Defined responsibilities
☐ Defined process steps
☐ Evidence of execution
☐ Required approvals
☐ Access controls
☐ Security requirements
☐ Exception records
☐ Incident records where applicable
☐ Corrective actions
☐ Periodic review
☐ Change history
☐ Evidence of effectiveness

---

38. Final Operating Procedure Audit Trail

For every important operating procedure, the organization should be able to answer:

Why does this procedure exist?

Who owns it?

When is it triggered?

Who performs it?

What exactly must be done?

What security requirements apply?

What information and systems are involved?

What evidence is generated?

What happens when something goes wrong?

How are exceptions handled?

How is effectiveness verified?

When was the procedure last reviewed?

Final Principle

A good operating procedure is not simply a document describing work. It creates a repeatable, controlled, and auditable way of performing the work.