SD Elements helps youcomply with

sd elements helps you comply with


AI2 Acquire and Maintain Applciation Software
Process Description Acquire and Implement Applications are made available in line with business requirements. This process covers the design of the applications, the proper inclusion of application controls and security requirements, and the development and configuration in line with standards. This allows organisations to properly support business operations with the correct automated aplications.

iso 270001 2013

A.14.1.1: Information security requirements analysis and specification
The information security related requirements shall be included in the requirements for new information systems or enhancements to existing information systems.

A.14.2.1 Secure development policy
Rules for the development of software and systems shall be established and applied to developments within the organization.

A.14.2.5 Secure system engineering principles
Principles for engineering secure systems shall be established, documented, maintained and applied to any information system implementation efforts.

pci dss 3.0

6.3 Develop internal and external software applications (including web-based administrative access to applications) securely

  • In accordance with PCI DSS (for example, secure authentication and logging)
  • Based on industry standards and/or best practices.
  • Incorporating information security throughout the software-development life cycle
  • Note: this applies to all software developed internally as well as bespoke or custom software developed by a third party.

6.5 Prevent common coding vulnerabilities in software-development processes:

  • Train developers in secure coding techniques
  • Develop applications based on secure coding guidelines


Security Controls Implementation » Systems Development, Acquisition, and Maintenance » Software Development and Acquisition
Development projects should consider automated controls for incorporation into the application and the need to determine supporting manual controls. Financial institutions can implement appropriate security controls with greater cost effectiveness by designing them into the original software rather than making subsequent changes after implementation.

Financial institutions should develop security control requirements for new systems, system revisions, or new system acquisitions. Management will define the security control requirements based on their risk assessment process evaluating the value of the information at risk and the potential impact of unauthorized access or damage


Application development should incorporate appropriate security controls, audit trails, and activity logs.


The development process provides important indicators of code trustworthiness. The primary indicators are the extent to which security is incorporated within development and personnel processes, and the level of process maturity. Specific features include:

  • Establishment of security requirements, considering the current and expected threat, network, and host environments;
  • Establishment of functional requirements and acceptance criteria;
  • Use of secure coding standards;
  • Tests and reviews for compliance with security requirements;
  • Background checks on employees and code development and testing processes;
  • Signed nondisclosure agreements to protect the financial institution's rights to source code and customer data as appropriate;
  • Restrictions on developer write-access to production source code and systems, and monitoring developer access to development systems; and,
  • Physical security over developer work areas, including restrictions on media taken to and from the work area.

Development and Acquisition » Development Procedures » Systems Development Life Cycle » Initiation Phase
Primary issues organizations should consider when compiling feasibility study support documentation include: ... Functional Requirements: ... - Internal control and information security requirements;

Development and Acquisition » Development Procedures » Systems Development Life Cycle » Design Phase
Designing appropriate security, audit, and automated controls into applications is a challenging task. Often, because of the complexity of data flows, program logic, client/server connections, and network interfaces, organizations cannot identify the exact type and placement of the features until interrelated functions are identified in the design and development phases. However, the security, integrity, and reliability of an application is enhanced if management considers security, audit, and automated control features at the onset of a project and includes them as soon as possible in application and system designs. Adding controls late in the development process or when applications are in production is more expensive, time consuming, and usually results in less effective controls. ...

NIST 800-37

(from main text) Security controls are typically traceable to the security requirements established by the organization to ensure that the requirements are fully addressed during design, development, and implementation of the information system. Security controls can be provided by the organization or by an external provider.


Requirements definition is a critical part of any system development process and begins very early in the life cycle, typically in the initiation phase.


Without the early integration of security requirements, significant expense may be incurred by the organization later in the life cycle to address security considerations that could have been included in the initial design. When security requirements are considered as an integral subset of other information system requirements, the resulting system has fewer weaknesses and deficiencies, and therefore, fewer vulnerabilities that can be exploited in the future.


Early integration of information security requirements into the system development life cycle is the most cost-effective and efficient method for an organization to ensure that its protection strategy is implemented."

Identify the security controls that are provided by the organization as common controls for organizational information systems and document the controls in a security plan (or equivalent document). Primary Responsibility: Chief Information Officer or Senior Information Security Officer; Information Security Architect; Common Control Provider.

Select the security controls for the information system and document the controls in the security plan. Primary Responsibility: Information Security Architect; Information System Owner

NIST 800-53

Control: The organization: a. Requires that information system developers follow a documented development process that: Explicitly addresses security requirements; Identifies the standards and tools used in the development process; and - Documents the specific tool options and tool configurations used in the development of the information system; and b. Reviews the development process, standards, tools, and tool options/configurations to ensure that the process, standards, tools, and tool options/configurations selected and employed will lead to satisfying organizational security requirements.

Control: The organization requires that information system developers produce a design specification and security architecture for the system that: Is created as an integral part of the system development process; - Is consistent with and supportive of the security architecture within the enterprise architecture; Accurately and completely describes the required security functionality, and the allocation of security controls among physical and logical components; Expresses how individual security functions, mechanisms, and services work together to provide required security capabilities and a unified approach to protection.

iso/iec 27034

ISO/IEC 27034-2 - Organization normative framework
SD Elements can serve as the Organization Normative Framework (ONF), with tasks as Application Security Controls (ASC) and testing tasks serving as validation instructions for the ASCs. Using SD Elements task priorities allows organizations to approximate Targeted Levels of Trust.

OSFI Cyber Security Guidance

Section 4.8
The FRFI’s internally or externally developed software is subject to secure system design, coding and testing standards that incorporate appropriate cyber security controls.

sd elements helps you build in these standards

  • PCI-DSS 2.0 and 3.0
  • PA-DSS 2.0 and 3.0
  • ISO 27001, 2005 and 2013
  • NIST 800-53
  • GLBA
  • SOX
  • EU Privacy and Cookie Laws
  • California Privacy Act
  • GAPP (Generally Accepted Privacy Policies)
  • ISA/IEC 62443-3-3

Interested in SD Elements? Contact our sales team for a demonstration.