Valid until: 2025-04-10

Classification: Low

Version Management

Purpose & background

In the interest of all the stakeholders, the top management of anDREa B.V. (hereafter called anDREa) is actively committed to demonstrably maintain and continually improve an information management system in accordance with the requirements of the ISO 27001:2017.

The purpose of this document is to describe the operating procedures of anDREa and the associated controls, checks and administrations. 

This document will be reviewed at least annually and when significant change happens.

Objectives

The objectives of this control are:

• To ensure correct and secure operations of information processing facilities (A.12.1).

Scope

The scope of this document corresponds to Clause 4 Context of the organisation.

Availability

This document is:

• required reading for:

• all employees and contractors of anDREa.

• available for all interested parties as appropriate.

Norm elements

A.12.1 Operational procedures and responsibilities

A.12.1.1 Documented operating procedures

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. AAD Configuration

2. System Subscription Prerequisites configuration

3. Networking and Firewall setup

4. AADDS 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

Support and Escalation Contacts

System Restart and Recovery Procedures

Monitoring procedures

Core

Human manned active 24/7/365 monitoring

Subscriptions

PIM

SaaS Development procedures

Overview

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
  

• Operations Manager

• 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.

Backlog

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 Development branch

• PBIs are picked up by the owners in order of priority provided by anDREa's Operations Manager 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 branch by the owner of the PBI.

• PBI on Test branch

• See: A.14.2.8 System security testing & A.14.2.9 System acceptance testing

• PBI on Acceptance branch

• Acceptance testing by Support & Assurance team

• Sign-off by Operations Manager 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 Operations Manager.

• Ready to deploy to Production

New PBIs

• By default no new PBIs can be added to a sprint

• New PBIs can be added after approval of the Operations Manager or Scrum Master

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 Operations Manager 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 Azure DRE 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

Planning

• When PBIs are ready to be deployed to production

• Plan when PBI will be deployed to production

• Notify (C)ST

Deploy

• PBI on Production branch

• Smoke testing

• Release notes published on anDREa Knowledge Base

• PBI is set to Done

PBI and Bug states

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

Acceptance

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.