Select Page

SDLC and QA Policy

{Company name as you’d like it to appear in your policy:6} SDLC and QA Policy

Last Updated: {date_today:9}

Created By: {user_displayname:10}


SDLC and QA Policy

Security should be taken into account early in the lifecycle, to ensure maximum flexibility in implementing required security controls. This System Development Lifecycle and Quality Assurance (SDLC/QA) policy applies to all {Company name as you’d like it to appear in your policy:6} systems, whether they are developed in-house or purchased and integrated into our operations.

Key Takeaways

  • {Company name as you’d like it to appear in your policy:6} follows a defined System Development Lifecycle (SDLC) to govern the development and/or acquisition of systems.
  • All systems must have identified security requirements and relevant tests performed to ensure the requirements are met.
  • Change and Configuration Management processes are required to ensure systems are configured correctly and only undergo approved changes.
  • Quality Assurance (QA) procedures must be followed to ensure systems are adequately tested to meet requirements.

Overview, Purpose, and Scope

Computer systems in use at {Company name as you’d like it to appear in your policy:6} require protection to ensure the data we handle remains secure. Rather than try to secure systems after they are implemented, we take security into account early in the lifecycle, to ensure maximum flexibility in implementing required security controls.

This System Development Lifecycle and Quality Assurance (SDLC/QA) policy applies to all {Company name as you’d like it to appear in your policy:6} systems, whether they are developed in-house or purchased and integrated into our operations. These requirements cover all systems where {Company name as you’d like it to appear in your policy:6} data is stored, processed, and transmitted.

Roles & Responsibilities

Senior management at {Company name as you’d like it to appear in your policy:6} is responsible for enforcing adequate SDLC/QA processes, while system owners are responsible for implementing the requirements identified in this policy.

{Company name as you’d like it to appear in your policy:6} management reviews and approves this policy, but if you identify an issue you should bring it to the attention of your manager.

Requirements

Formal System Development Lifecycle (SDLC)

All systems at {Company name as you’d like it to appear in your policy:6} follow a lifecycle, and each phase of the lifecycle has unique security considerations which must be reviewed before progressing to the next phase. This policy dictates the high level requirements for system development at {Company name as you’d like it to appear in your policy:6}; for further reference please see NIST Special Publication 800-64, Security Considerations in the System Development Life Cycle.

The phases of the SDLC are as follows:

  • Initiation: During this phase, decisions such as available budget, build vs. buy, and the project kickoff are conducted. System requirements must be identified during this phase, and must include system and data security.
    • Key security concerns include categorizing the type of information to be processed by the system (see Data Security Policy), privacy requirements, and initial assessment of risks presented by the proposed system.
  • Development/Acquisition: This phase encompasses the building of an in-house system, or acquisition and integration of commercial software. During this phase it is important to include routine security activities such as code review and system testing.
    • Key security concerns include ensuring a secure system design/architecture, conducting a formal risk assessment of the proposed system, and selecting/implementing any additional security controls as indicated by the risk assessment.
  • Implementation: Once the system is designed, it must be implemented with all relevant security controls identified in prior steps.
    • Key security concerns include formal assessment of the final system security posture (verifying that chosen controls have been properly implemented), and formal acceptance of the system before it is placed into production, and properly entering the information system and its components into the Configuration Management and Asset Inventory systems.
  • Operations and Maintenance: Once the system is operational, it is important to keep a current understanding of the security posture and any new risks.
    • Key security concerns include proper configuration & change management procedures, routine reassessment of system risk, and routine retesting of security controls in place on the system.
    • During Operations & Maintenance, the majority of security concerns should be managed and evaluated as part of risk assessment and management practices. See the Risk Assessment & Management Policy for further reference.
  • Disposal: At the end of a system’s lifecycle it must be decommissioned and securely disposed of.
    • Key security concerns include preservation of data according to retention requirements (see Backup & Retention Policy), secure destruction of data, and securely disposing of any hardware in use (including data destruction).

Configuration and Change Management

During the Implementation phase, all systems and their components (hardware and software) must be inventoried and placed into a Configuration Management Database (CMDB). The CMDB should include relevant data, including version information, owner, and data classification level for all assets. Note: the CMDB may be automatically generated by a variety of tools, such as cloud hosting dashboards, continuous integration/continuous deployment tools (CI/CD), etc.

Systems at {Company name as you’d like it to appear in your policy:6} must be kept in known secure states at all times to ensure the security of data they process and store. It is therefore essential that formal change control procedures be implemented which meet the following requirements:

  • Change control must be a formal process which requires a request, review of proposed change, and approval of any system changes. Systems processing/storing Restricted data must utilize change control, while systems processing/storing Internal or Public data should utilize change control (See Data Security Policy).
  • As part of change control, a technical review of the system should be conducted to identify any security impacts of the change. If needed, additional security controls may be required as part of approval for the change.
  • Configuration audits should be conducted periodically to verify that the system’s current status matches the documented configuration (taking into account approved changes).

Security of Application Development Environments

At a minimum {Company name as you’d like it to appear in your policy:6}’s Production (Prod) environments must be logically separated from non-Prod environments such as Test, QA, and Staging. This separation may include one or more of the following: separate access credentials, physical/logical network segregation, and prominent identification of the environment and its elements, such as hostnames, IP addresses, application names, and warning banners.

No Prod data may be used in a non-Prod environment without first being sanitized or anonymized.

Due to the sensitivity of source code any systems development environments used at {Company name as you’d like it to appear in your policy:6} must have additional security in place. Considerations should include restricted access for relevant members of development teams, separation of duties controls to prevent developers from pushing code into production environments, and access restrictions based on work assignment (i.e. developers must match code developed to a specific feature request or requirement).

Quality Assurance Policy

The quality of systems at {Company name as you’d like it to appear in your policy:6}, whether built in house or bought, must be verified. To achieve this, a Quality Assurance (QA) function must exist; this function shall have responsibility for testing and verifying that systems being used properly meet {Company name as you’d like it to appear in your policy:6} policies and controls. The QA function may not have direct responsibility for conducting testing, but does have the authority to ensure testing is conducted which meets {Company name as you’d like it to appear in your policy:6}’s defined standards.

System and Security Testing

Security Testing is to be done by independent QA function. This may be achieved by the use of QA resources outside of the system development/acquisition process, or by resources with separated duties within the development/acquisition process (i.e. a developer who writes code or integrates a system component can not be the one to test it).

The scope of system and security testing should include:

  • Functional system testing (fitness for purpose)
  • Unit testing (individual components work as expected)
  • Security testing (do controls function as intended, how does the system handle misuse cases, and other security testing such as penetration tests, vulnerability scans, etc.)

Enforcement

Any exceptions to this policy must be approved by senior management in writing.

Any user found to have violated this policy will be subject to disciplinary actions, up to and including termination of employment.

You don't have credit card details available. You will be redirected to update payment method page. Click OK to continue.