Software Development Lifecycle

13 minute read

Purpose

This policy defines the high-level requirements for providing business programme managers, business project managers, technical project managers, and other project stakeholders guidance to support the approval, planning, and life-cycle development of intelliHR software systems aligned with the Information Security programme.

Roles and Responsibilities

Role	Responsibilities
intelliHR Team Members	Responsible for following the requirements in this procedure
Engineering Managers	Responsible for implementing and executing this procedure
Engineering Management	Responsible for approving significant changes and exceptions to this procedure

Policy

intelliHR must establish and maintain processes for ensuring that its computer applications or systems follow a System Development Life Cycle (SDLC) process which is consistent and repeatable, and maintains information security at every stage.

Policy Objectives

Establish appropriate levels of management authority to provide timely direction, coordination, control, review and approval feature development
Document requirements and maintain traceability of those requirements throughout the development and implementation process
Ensure that projects are developed within the current, planned and approved infrastructure

Access Control

Segregation of Environments

Development will be performed in a dedicated environments, separate from quality assurance and production.

Quality Assurance will be performed in dedicated environments, separate from production and development.

Segregation of Duties

Development and quality assurance duties will be conducted with de-identified and separate datasets, so as to reduce as much exposure to live customer data which may contain sensitive records.

In exception to this, engineering team members required to attend to incidents as part of their on-call duties may require access to customer data to diagnose and resolve issues. Such access will limited to affected tenants for the purpose of resolving the issues.

Customer Success, Account Management and Support team members may maintain access to customer tenants and their data in order to fulfil their duties (which are external to the SDLC detailed here).

System Development Life Cycle Phases

A Software Development Project consists of a defined set of phases:

Envision

In line with intelliHR’s vision to transform workplaces for the better, product management and company executives determine the needs of customers and the causes that they may have to implement intelliHR’s platform and products.

Strategise

To bring intelliHR’s vision into reality, the product team determine features, products and offerings to be delivered to address customer needs and streamline implementation.

Alternative solutions and conflicting priorities are welcome during this phase.

Select

The product team alongside engineering management determines the most valuable projects to bring into team roadmaps for investigation and board analysis.

Success criteria and proposed investment of resources for the project are also determined during this phase.

Explore

The product team delivers a problem statement and determines success criteria for the project to an applicable team. This may be based on customer workshops, feedback, market research or in effort to lead industry expectations.

Visual representations and prototypes of the proposed solutions may be generated at this phase, in order to gain customer feedback.

Design Solution

The Engineering team investigates execution methods to achieve the desired solution. The team will endeavour to produce a solution that is:

Incrementally deliverable, in order to receive customer feedback as regularly and early as possible
Extensible and scalable, in order to accommodate customer requirements that may not yet be in scope
Reliable and reproducible, in order to reduce dependency on vendors, platforms and technologies as much as possible
Measurable, in order to monitor effectiveness for future work

Together with the Chief Technology Officer and any relevant principle engineers, the most valuable solution is determined with a broad estimate.

If visual prototypes of the solution are required and are not yet validated, they will be produced and validated during this phase by the Product & Design team.

The solution is broken down into increments that can be released in order, each having their own broad estimates (relevant to agile sprints).

Build

The Enginering team selects the first deliverable increment and breaks it down into component tasks, each given a numeric weighting. These tasks are assigned to work iterations (sprints) based on their priority and against maintained estimates for that team’s iteration velocity.

The Enginering team executes these tasks as part of their day-to-day duties. Commonly these tasks require the production of code assets that are persisted within version control platforms (Git).

The Enginering team, together with dedicated quality assurance team members will produce unit, regression and automated test assets to ensure reliability and maintenance of their work. These assets are also maintained in version control platforms.

Once a body of work is determined to be nearing releasable, demonstration and feedback sessions are conducted internally. Once any issues from those sessions are resolved, external sessions and presentations are conducted by customer success or account management team members.

Once any issues are resolved to the satisfaction of stakeholders, the body of work is deemed fit for limited release.

Adopt

As new bodies of work are deemed fit for limited release the following may occur:

training material and release notes produced for intelliHR team members
training material produced for the benefit of customers
opt-in customers are nominated, and the new body of work is released behind a feature flag for their evaluation
product team and executives may determine a new feature or offering to be fit for general access

After the above, a body of work may be determined fit for general access. If so, any feature flags are removed and the change is made available to all customers.

Evaluate

All interactions with the intelliHR platform and products are monitored using de-identified methods. This monitoring allows the Engineering and Product teams to report on the engagement, uptake and overall success of any changes they produce.

After any major releases, the metrics capturing included in the body of work (from the Design Solution phase) are monitored and evaluated against the success criteria for the project (from the Select phase).

Customer feedback may also be taken during this phase.

The output of these metrics and customer feedback is recorded and used to inform future Select and Explore phases.

SDLC Security Control Guidelines

The SDLC process will adhere to the following information security controls:

Adequate procedures should be established to provide separation of duties in the origination and approval of source documents. This shall include, but not be limited to, separation of duties between Personnel assigned to the development/test environment and those assigned to the production environment
Modification of code or an emergency release will follow the change control standard
Secure programming standards should be followed. Secure code training should be provided to intelliHR’s developers
Secure development environments will be created, based on:
- sensitivity of data to be processed, stored, and transmitted by the system
- applicable external and internal requirements, for example, from regulations or policies
- security controls already implemented by the organisation that support system development
- trustworthiness of personnel working in the environment
- the degree of outsourcing associated with system development
- the need for segregation between different development environments
- control of access to the development environment
- monitoring of change to the environment and code stored therein
- backups are stored at secure offsite locations
- control over movement of data from and to the environment
All software deployed on Corporate or Hosted infrastructure must prevent security issues including but not limited to those covered by SAN and OWASP
Code changes are reviewed by team members other than the originating code author and by team members who are knowledgeable in code review techniques and secure coding practices
Overrides of edit checks, approvals, and changes to confirmed transactions should be appropriately authorised, documented, and reviewed
Application development activity should be separated from the production and test environments. The extent of separation, logical or physical, is recommended to be appropriate to the risk of the business application or be in line with customer contractual requirements. The level of separation that is necessary between production, development, and test environments should be evaluated and controls established to secure that separation
All changes to production environments should strictly follow change control procedures, including human approval of all changes, granted by an authorised owner of that environment. Automated updates should be disallowed without such approval
Active production environments should not be re-used as test environments. Inactive and/or decommissioned production environments should not be used as test environments unless all private data has been removed. Test environments should not be re-used as production environments without going through a decommissioning and recommissioning process that cleans all remnants of test data, tools, etc.
Team members who are responsible for supporting or writing code for an internet-facing application, or internal application that utilises web technology and handles customer information, should complete annual security training specific to secure coding practices. For team members supporting or writing code for an internet-facing application, training should also include topics specific to internet threats. The team member should complete the training prior to writing or supporting the code. The training must include OWASP secure development principles as well as OWASP top 10 vulnerability awareness for the most recent year available
Custom accounts and user IDs and/or passwords should be removed from applications before applications become active or are released to customers
Production data should not be used in testing or development environments
Security controls that are in place for the production copy in the test system should be production quality (for example, mirroring the production controls over the data)
When conducting quality assurance (QA) testing prior to the release of a new feature requiring user input where constraints on user input may be reasonably understood, feature acceptance tests must include testing of edge and boundary cases

For situations demonstrating that testing needs to use production data, the requirements are the following:

The Information Resource Owner will provide approval before production data can be used for testing purposes
Wherever possible, the production data should be tokenised or anonymised instead of using production data directly
Testing and parallel runs should use a separate copy of production data and the test location or destination should be acceptable (for example, loading confidential production data to a laptop for testing is not acceptable)
The data should not be extracted, handled, or used by the test process in a manner that subjects the data to unauthorised disclosure
The data should be accessed on a need-to-know basis
Normal test activities should not use production data. In cases where test activity requires access to production data, access to production data should be restricted to only those team members who have a documented business need. Only the information with the documented business need should be accessible by those users
Production data used for testing should be securely erased upon completion of testing
Test data and accounts will be removed before being placed into production
Restricted/Protected Information will be encrypted according to the Encryption Standard while at rest or in transit
Error messages must be handled securely and they must not leak sensitive information

Change Management

Software Installation and Change on Operational Systems

Operating system applications and software will only be implemented after extensive and successful testing. The tests will cover:
- Usability
- Security
- Effects on other systems
- User-friendliness
- Tests will be conducted on separate systems (test environment), and all corresponding programme source libraries will also be updated, as appropriate
The operational software, applications, and programme libraries of intelliHR will only be updated by trained team members upon appropriate management authorisation
Company operational systems will only hold approved executable code, not development code or compilers
A configuration control system will be used to keep control of all implemented software as well as the system documentation
- Previous versions of software will be retained as a contingency measure
- Old versions of software will be archived, together with all required information and parameters, procedures, configuration details and supporting software for as long as the data are retained in archive
There will be a rollback strategy in place before changes are implemented
An audit log will be maintained of all updates to operational programme libraries
All decisions to upgrade to a new version release must take into account:
- Business requirements for the change
- Security of the release, for example, the introduction of new information security functionality or the number and severity of information security problems affecting this version

Change Control Procedures

A record of agreed authorisation levels will be maintained
Changes are only submitted by authorised users
Controls and integrity procedures will be reviewed to ensure that they will not be compromised by the changes
All software, information, database entities and hardware that require amendment will be identified
Security critical code to minimise the likelihood of known security weaknesses will be identified and checked
Formal approval must be obtained for detailed proposals before work begins
Authorised users must accept changes prior to implementation
Changes will be implemented at a time that is least intrusive to business processes involved
Vendor-supplied software will be used without modification; in the event that a modification is necessary, the following will be evaluated:
- Risk of compromising built-in controls and integrity processes
- Vendor consent
- Getting the modifications from vendor as standard updates
- Impact of owning the responsibility for maintaining the programme
- Compatibility with other software in use
A technical review of applications will be conducted after changes to operating platforms (operating systems, databases, and middleware platforms). The review will include:
- Application control and integrity procedures to ensure that they have not been compromised by the operating platform changes
- Timely notification of operating platform changes to allow appropriate tests and reviews to take place before implementation
- Appropriate changes are made to the business continuity plans

Compliance

Compliance Frameworks

All users of the intelliHR platform and products are prompted to give affirmative and informed consent to store and process their personal information. When users do not consent, or withdraw consent, tenants are notified and any access or user data is removed.

ISO27001 / SOC2

intelliHR is in the process of acquiring these certifications. Please enquire for full details.

PCI DSS

intelliHR’s product offerings do not store payment card information, nor process payments, so does not require, or maintain PCI DSS compliance.

Record of changes

Date	Version	Modifier
2022-08-02	1.0	Andrew Smith / Sam Wolski

Glossary

Term	Definition
Account Management	intelliHR’s Account Management department and team members, dedicated to resolving customer issues and increasing customer retention.
Agile Sprints	Consistent iterations of software development, consisting of planning, kick-off, and retrospective sessions. Agile sprints are intelliHR’s main vehicle for monitoring SDLC process and implementing changes to process.
Chief Technology Officer	The intelliHR board representative ultimately responsible for all software development within the company.
Customer Success	intelliHR’s Customer Success department and staff, dedicated to understanding customer needs and implementing of the intelliHR platform to solve those needs.
Domain Team	Cross-discipline groups of engineers and engineering-support staff, each dedicated to a product area and the long term goals of that area.
Executives	intelliHR’s board representatives
Feature Flag	A function of the intelliHR infrastructure that allows for elements of the system to be altered or disabled for individual customers, or groups of customers.
Git	A Version Control technology, employed by intelliHR.
Product Team	intelliHR’s Product department and staff, dedicated to market and customer analysis, setting strategy for the product domain teams, and evaluating success of product changes.
Product Management	Senior management staff at intelliHR ultimately responsible for determining product strategy.
Principle Engineer	A senior engineer nominated to take responsibility for a facet or domain of the intelliHR infrastructure or product offerings.
Quality Assurance	intelliHR’s engineering team dedicated to ensuring reliability and quality improvement of intelliHR product offerings. Often these staff are embedded into a domain team.
Release	The process of rebuilding a set of services with updated code assets, making those services publicly available and decommissioning the outdated services once replaced.
Support	intelliHR’s Support team, dedicated to resolving customer queries, triaging bug reports, and handling incidents or interruptions of service.
Version Control	A cloud-based technology to store code assets and keep detailed records of changes over time.