Review and revision metadata

Review Date: 2026-07-05

Reviewer: Operations Manager

View revision history and auditor diffs on GitHub

previous version on gdrive

A.5.37 Documented operating procedures

Control Objective

Operating procedures for information processing facilities shall be documented and made available to personnel who need them.

Policy Statement

anDREa ensures the secure, consistent, and predictable operation of its information processing systems by formalizing technical workflows into standard operating procedures (SOPs). These procedures are maintained, kept accurate, and securely distributed to relevant operational personnel.

Due to the exhaustive nature of the technical instructions required to manage the myDRE infrastructure under ISO/IEC 27001 and NIS 2 standards, this control is fully operationalized within its own dedicated handbook.

---

Reference Document

Installation and Configuration of Systems

Github

1. Github Organization setup
2. Github AAD SAML Auth Configuration
3. Branch Policies
4. Actions configuration
5. Security and Vulnerability scanning with Dependabot

Shared Tenant

1. EntraID Configuration
2. System Subscription Prerequisites configuration
3. Networking and Firewall setup
4. Microsoft Entra Domain Services Configuration
5. Domain and Certificates
6. DevOps Configuration for deploying the myDRE System components

DevOps

1. Azure DevOps Account Provisioning
2. Azure DevOps AAD SAML Authentication configuration
3. Azure DevOps Service Principal configuration
4. Initial Pipeline run to provision and configure myDRE System infrastructure

Processing and Handling of Information

both automated and manual;

Backup

Item	Method	Status
Code	In ESCROW / GitHub	Operational
myDRE support	Backup of Zoho Desk	Operational
DevOps	Covered in Microsoft SLA	Operational
Google Drive	Covered in Google SLA	Operational
Workspace data (seemydre CIA-AA Classification)*	30 day 24h rolling snapshots	Operational

Support and Escalation Contacts

See:

• Tenant Configurations
• Security & Privacy Contacts

System Restart and Recovery Procedures

See:

• Disaster Recovery Plan

Monitoring procedures

Core:

• Active 24/7/365 monitoring

Subscriptions:

• PIM

SaaS Development procedures

Below is depicted anDREa’s workflow for development, testing, deployment and hotfixes.

The development methodology is Scrum-based. This is explained in the following paragraphs.

Development Team Roles

The following development team roles are used:

• Product Owner
• Architect
• Lead developer
• Developer
• Ops
• Support & Assurance team
  • Tester
  • Support
  • Security Officer (Management TEam)
  • Product Owner Scrum Master

Scrum Development Cycle

Below is depicted the Scrum development cycle. All the activities are planned in Teams. All Product Backlog Items (PBIs) are added and documentation is done in DevOps. In the next sections each of the activities is explained.

Backlog

Discuss product backlog, future sprint backlog(s) and pending activities for backlog grooming.

Grooming

• If a PBI is over 60 hours, the PBI must be separated into two or more items
• All PBIs & Bugs should have:
  • Description or Reproduction Steps
  • Acceptance Criteria
• A PBI can have one of two phases, which cannot be in one sprint
  • Design/Proof of Concept
  • Build
• All tasks must have an owner assigned to them before Sprint Commit Session

Planning

• Add sprint capacity in DevOps
• Discuss all Approved PBI's and Bugs
  • items without description/acceptance criteria will not be discussed
• Assign Owners to PBI’s and Bugs
• Estimation (as a team) via DevOps

Commit

• Discuss created tasks and task-specific estimation (based on hours) per PBI
• Commit as a team to the estimated backlog

Execute

• PBI on Feature branch
  • PBIs are picked up by the owners in order of priority provided by anDREa's Product Owner and Scrum Master
  • PBI-specific & generic tasks are created by the owner of the PBI or Scrum master
  • All tasks are done when:
    • The state is set to Testing
    • Deployment of PBI to Test (TST) Environment by the owner of the PBI
• PBI on Test Environment
  • See: A.08.29 - Security testing in development and acceptance
• PBI on Acceptance Environment
  • Acceptance testing by Support & Assurance team
  • Sign-off by Product Owner after discussion in Support & Assurance meeting > GO/NO GO
  • The state is set to Ready for Production once the acceptance environment is signed off by the Product Owner
  • Ready to deploy to Production

New PBIs

• New PBIs
  • By default no new PBIs can be added to a sprint
  • New PBIs can be added after approval of the Product Owner or Scrum Master

Daily

• Daily
  • If new PBIs are added, the impact is discussed and which of the current Sprint PBIs should be moved to the backlog

Review

• Inform Product Owner which items are completed and in which way
  • What has been delivered, what problem does it solve, what is the impact on the user and/or business
• Acceptance test by Support & Assurance team
• 10-minute time slot per developer to present
• Items are completed when:
  • PBI or bug and its child items are set to 'Done' in DevOps
  • PBI or bug set to 'Done' means that they are:
    • Live in production, or
    • Added to the myDRE codebase
• The target audience is not technical
• Sprint Review sessions will be captured and made available to (Core) Support Team and other Stakeholders

Retro

• Retrospective via DevOps Retrospective tool

Release Planning

• When PBIs are ready to be deployed to production:
  • Plan when PBI will be deployed to production
  • Notify (Core) Support Team ((C)ST)

Deploy

• PBI on Production branch
• Smoke testing
• Release notes published on anDREa Knowledge Base
• PBI is set to Done

Deployment Governance

Approval and Rollback: To ensure the security and continuity of operational systems, all software installations and updates to the production environment must adhere to the following strict governance procedures:

1. Automated Deployment via Infrastructure as Code (IaC)

   • All infrastructure changes and software deployments must be executed using automated pipelines (Azure DevOps) defined in code (ARM/Bicep/YAML). Ad-hoc manual changes are generally prohibited; IaC pipelines should be used unless a manual change is absolutely necessary. except for emergency break-glass scenarios which must be logged as incidents.

2. Formal Deployment Approval Workflow

   • Pre-Deployment Gate: Before any code or infrastructure change is released to Production, a formal "Release Gate" in Azure DevOps is enforced.
   • Approval Authority: The Product Owner (or mandated delegate from the Support & Assurance team) must explicitly approve the release in the system.
   • Criteria: Approval is contingent upon the successful completion of the "Acceptance" phase, including passing automated regression tests and the "GO" decision from the Support & Assurance meeting.

3. Rollback Procedure

   • Trigger: In the event of a deployment failure, service disruption, or critical bug discovery immediately following a release.
   • Procedure:
     1. Immediate Revert: The deployment pipeline is used to redeploy the previously known good artifact/commit.
     2. State Fix: If a deployment alters database schemas or data state in a manner that cannot be safely or immediately reverted, the Development Team shall restore the most recent automated database backup taken immediately prior to the schema change, in accordance with the approved rollback and recovery procedures for the affected component. .
     3. Incident Log: All rollbacks are classified as incidents and must be logged in Issues and Risk Logging and this will require a Root Cause Analysis (RCA) and might result in a Corrective action Plan.

PBI and Bug states

Status	Description / Criteria
New	• Item is newly added to the product (or future sprint) backlog. • PBI’s will by default not be added to the current and committed sprint backlog. • Bugs and VIP BPIs can be added to the current sprint backlog, only after a discussion with PO or Scrum Master.
Approved	• Item has been approved by the Product Owner (or in some cases Scrum Master). • Description, Acceptance Criteria and Value area fields are filled correctly.
Committed	• Item is discussed during sprint planning. • All tasks for this item are created correctly by assigned Devteam members. This means that they are assigned to a Devteam member and the ‘Remaining effort’ field is filled in with the estimated hours. • (If applicable) All tasks are discussed with all Devteam members that will work on that item (so they are aware of tasks in unassigned PBI’s/Bugs). • Item is set to commit during the Sprint Commit session.
Testing	• All tasks are set to done (except tasks like ‘Merge to master’, ‘PR review’, ‘Deploy to production’). • The state of the item is set to Testing by the assigned Development team member. • Test plan is created and reviewed. • Tester is working on testing this item. • Acceptance testing tasks are created. • PBI is marked as Ready for Acceptance.
Acceptance	• Testing by the tester has passed and the code has been pushed to Acceptance. • Test plan is validated on Acceptance. • Findings are registered in the PBI and test plan. • After testing, findings are either resolved or it can move to the next stage: GO or NO GO in the Support & Assurance team meeting. • If it is a GO, the PBI is marked as Ready for Production.
Completed	• Work on the item has been completed. • The reason for the state has been added in the Comment section of Description field. • Item has not yet been approved by (technical) Product owner or item does not meet the definition of done criteria set by the development team and the management.
Done	• Item is approved by (technical) Product Owner. • Item is fully deployed on anDREa Production and all communication to stakeholders has taken place (Release notes, instructions, etc).
Removed	• Items are removed from the backlog, but not deleted from the backlog. • Removed items are still searchable in DevOps. • The reason for removal is added in the Comment section or Description field.