35. HealthSafe Secure Development Policy

SECURE DEVELOPMENT POLICY

Document Identification	HSNZ/POL/35
Document Name	Secure Development Policy
Master Copy	CISO
Version Number	1.2
Date Of Release	15 Aug 2023
Prepared By	Eparama Tuibenau	CISO
Approved by	Kevin McAfee	Managing Director

 

VERSION HISTORY

Sl No	Version No.		Prepared by	Approved by	Description of Version	Date	Reason for Version Change
	From	To
1	1.0	-	CISO	MD	Current	04 Jul 2021	No changes made
1	1.0	1.1	CISO	MD	Reviewed	28 Jul 2022	Annual review
1	1.1	1.2	CISO	MD	Reviewed	15 Aug 2023	Annual review

DOCUMENT STATUS

Date	Document Status
04 Jul 2021	Reviewed
28 Jul 2022	Reviewed
15 Aug 2023	Current

Table of Contents

1 Purpose

2 Scope

3 Input

4 Output

5 Interacting Process

6 Abbreviations, Acronyms and Definitions

7 Procedure

8 Monitoring the Process

9 Records

1. PURPOSE
   The purpose of this document is to establish and maintain a policy for Secure Development procedures for HealthSafe NZ.
   
   
2. SCOPE
   These procedures applies to all aspects of Secure Development procedures
   
   
3. ABBREVIATIONS, ACRONYMS AND DEFINITIONS

Abbreviation	Description
FH	Functional Head
IT	Information Technology Department
TL	Team Lead
CISO	Chief Information Security Officer

4 INPUT

HealthSafe NZ will be responsible for the safety of all information that is stored or accessed through the various development environments.

5 OUTPUT

All users shall comply with the secure development policy in order to secure the information and intellectual property

6 INTERACTING PROCESS

Functional Head

7 PROCEDURE

HealthSafe NZ’s development process is based on Agile methodology utilising JIRA to follow this process. The following is an explanation of how HealthSafe NZ currently manages this process and each member of the HealthSafe team needs to be well aware of this mechanism in order to perform their tasks efficiently. 

Current roles:

• Product Owner
• Developers
• Quality Assurance
• Business Analyst

Sprint Planning (SP)

The first step is picking up the high priority level tasks from the Backlog (a list of necessary properties that have to be implemented during the development process). 

• The product owner is a person responsible for this. He/she bases on information from customers, the situation on the market and competition requirements and knows which functions or priorities of the product are the most needed.

Next points to discuss on the SP meeting:

• The delivery date.
• The number and functionality of release.
• The most important releases (selection).
• The list of packets (objects) for backlog items.
• The project team structure.
• Necessary tools.
• Risk control.
• Release plans 

After the planning there is a time for the system architecture. The HealthSafe production team reviews the backlog, thinks about what changes have to be made to implement new properties and designs the implementation process. Sometimes, there is a need to make some changes, refine the old product, gain some additional knowledge, analyse, solve problems or issues which appear during the process. At the end there are review meetings during which the teams exchange information , present progress and problems , reassign changes as required.

*Allocated buffer time for SP stage: 0.67 SP (2 hours) per person (each Sprint).

Stand-up Meetings (SUM)

The SUM meetings are usually time restricted between 5 and 15 minutes and documented via Slack channel ‘hs-stand-up’ to remind people to keep this information updated on a daily basis. The stand-up automated bot questions are sometimes also referred to as the "stand-up", "morning roll-call" or "daily scrum".

Before starting every day work in the stand-up reminders every person of the team says what he/she did yesterday, what will do today, and any problems they have encountered (if any).

Sprint Duration vs. Features Delivery (SD vs. FD)

The SD may last from 1 to 4 weeks (usually it's 2 weeks) and the duration should be constant in every cycle. However this requirement is not strict and sometimes the time of each sprint is different. The duration influences the speed and intensity of the process. The risk of going over schedule is monitored at all times.

"Support"

Allocated buffer time for Support: 2.7 SP per person - 8 Hours (each Sprint).

• This includes phone calls, email and text answers with Clients and H&S Team.

"Extra Requests" (ER)

The extra-requests are based on priority and the process of attending the extra-request is as following:

• A team member receives an extra-request.
• The extra-request is High Priority (this means that it’s on top of any current task).
• The extra-request fits in the allocated time for extra-requests.
• The team member perform the extra-request.
• The extra-request does NOT fits in the allocated time for extra-requests.
• Any current task assigned to the team member needs to be moved to the next Sprint.
• The extra-request is Medium/Low Priority task:
• The extra-request fits in the allocated time for extra-requests.
• The team member perform the extra-request.
• The extra-request does NOT fits in the allocated time for extra-requests.
• The extra-request is moved for the next Sprint.

"Sprint Review Meeting" and "Sprint Retrospective Meeting"

• The team show the results of the sprint and than the Product Owner assess if the goal has been achieved.
• The ScrumMaster and team decide which tasks were made appropriate and talk about how to make the process more effective.

"The Postgame Phase" (closure phase)

The management ends the development process and the product is being prepared for a release. This includes: 

• Integration
• Testing
• User documentation
• Training
• Marketing material preparation.

A different Sprint could be separately created for this phase including different team members (QA, BA, Marketing Team, etc).

8 MONITORING PROCESS

• The IT Department Monitors these process via JIRA project management tool

9 RECORDS

• JIRA release notes
• JIRA backlog