Compliance Framework Alignment
ISO/IEC 27001:2022 — A.8.25 Secure development life cycle ISO/IEC 27001:2022 — A.8.26 Application security requirements ISO/IEC 27001:2022 — A.8.27 Secure system architecture and engineering principles ISO/IEC 27001:2022 — A.8.28 Secure coding ISO/IEC 27001:2022 — A.8.29 Security testing in development and acceptance ISO/IEC 27001:2022 — A.8.30 Outsourced development ISO/IEC 27001:2022 — A.8.31 Separation of development, test and production environments ISO/IEC 27001:2022 — A.8.33 Test information (production data in test) SOC 2 (AICPA) — CC8.1 Change Management PCI DSS v4.0.1 — Requirement 6.2 (Bespoke and custom software developed securely) PCI DSS v4.0.1 — Requirement 6.3 (Security vulnerabilities identified and addressed) This policy is aligned with ISO/IEC 27001:2022, SOC 2 & PCI DSS v4.0.1. It operationalises ISO 27001 Annex A controls A.8.25–A.8.31 for the secure development life cycle, SOC 2 CC8.1 change management, and — where cardholder data is processed — PCI DSS v4.0.1 Requirement 6 for bespoke and custom software. Certification/attestation requires the controls below to be evidenced through the ISMS, a Type II audit, and/or a QSA-assessed PCI DSS report.
ACME TECHNOLOGIES PVT LTD SECURE DEVELOPMENT (SECURE SDLC) POLICY Aligned with ISO/IEC 27001:2022, SOC 2 & PCI DSS v4.0.1
Effective Date [Effective Date]
Review Date [Review Date]
Framework Alignment ISO/IEC 27001:2022, SOC 2 & PCI DSS v4.0.1
Policy Owner Vikram Patel
Vulnerability Reporting appsec@company.com Management Statement — CEO / CTO name (for management statement) , CEO/CTO:
Security is a first-class requirement in everything Acme Technologies Pvt Ltd builds. We are committed to embedding security throughout the software development life cycle — from design and threat modelling through coding, testing, review, and release — so that the software and services we deliver protect our customers' data by design and by default. This Policy establishes the mandatory rules by which we develop, test, and change our systems securely.
1. Purpose and Scope
This Secure Development Policy ("Policy") establishes mandatory rules for the secure development of software and systems at Acme Technologies Pvt Ltd , satisfying ISO/IEC 27001:2022 Annex A control A.8.25 (Secure development life cycle). It applies to all employees, contractors, and outsourced development partners who design, build, test, review, deploy, or change software — including web applications, APIs, mobile apps, infrastructure-as-code, and internal tooling, including all bespoke and custom software within the Cardholder Data Environment (CDE). The Policy covers the full software development life cycle (SDLC) and integrates with the Company's change management and information security programmes.
2. Secure Development Life Cycle Stages
Security activities are defined and enforced at each SDLC stage (A.8.25, A.8.27): (a) Requirements — security and privacy requirements are identified, specified, and approved for every application before development (A.8.26); (b) Design — architecture follows secure system engineering and defence-in-depth principles, and undergoes threat modelling (A.8.27); (c) Build — code is written to the Company's secure coding standards (A.8.28); (d) Test — code is subjected to security testing before acceptance (A.8.29); (e) Review & Approval — changes are peer-reviewed and formally approved (SOC 2 CC8.1); (f) Release — deployment follows the change control process to production; (g) Operate & Maintain — vulnerabilities and dependencies are monitored and patched throughout the product's life. Security gates at each stage must pass before work proceeds to the next stage.
3. Application Security Requirements and Threat Modelling
Information security requirements shall be identified, specified, and approved when developing or acquiring applications (A.8.26). For every new system, and for significant changes to existing systems, the development team shall perform threat modelling to identify assets, trust boundaries, threats (e.g. using STRIDE), and mitigating controls before design is finalised. Threat model outputs — including data-flow diagrams and an agreed set of security controls — shall be documented, reviewed, and retained as evidence. Security requirements shall address authentication, authorisation, session management, input validation, output encoding, cryptography, logging, and error handling.
4. Secure Coding Standards (OWASP Top 10)
All software shall be written in accordance with the OWASP Top 10 (2021) and OWASP Application Security Verification Standard (ASVS) and the Company's secure coding standard (A.8.28; PCI DSS 6.2.2, 6.2.4). Developers shall apply defined engineering techniques to prevent or mitigate common software attacks, including but not limited to: broken access control, cryptographic failures, injection (SQL, OS command, LDAP), insecure design, security misconfiguration, use of vulnerable and outdated components, identification and authentication failures, software and data integrity failures, insufficient logging and monitoring, and server-side request forgery (SSRF). Mandatory practices include input validation and output encoding, parameterised queries, least-privilege service accounts, secure secrets management (no hard-coded credentials or keys), and safe error handling that does not disclose sensitive information. Developers of software shall receive secure coding / application security training at least annually (PCI DSS 6.2.2).
5. Security Testing — SAST, DAST and SCA
Security testing shall be integrated into the development and acceptance process (A.8.29; PCI DSS 6.3.1). The CI/CD pipeline shall automatically run: (a) Static Application Security Testing (SAST) on every code change to detect insecure code patterns; (b) Software Composition Analysis (SCA) to identify known vulnerabilities (CVEs) and licence risks in third-party and open-source dependencies; (c) Secrets scanning to prevent credentials from being committed. Dynamic Application Security Testing (DAST) shall be performed against running builds before release, and independent penetration testing shall be conducted at least annually and after significant infrastructure or application changes. Bespoke and custom software shall not be released to production until identified critical and high-risk vulnerabilities are resolved or formally risk-accepted (PCI DSS 6.3.1, 6.3.3).
6. Code Review and Approval
All source code changes shall undergo peer code review before being merged and released to production (A.8.28; PCI DSS 6.2.3; SOC 2 CC8.1). Code review requires: (a) at least 1 independent reviewer(s) other than the author; (b) reviewers who are knowledgeable in secure coding techniques and the language/framework in use; (c) confirmation that the change adheres to secure coding standards and that security findings are corrected before approval; (d) an auditable record of the review and approval retained in the version control / pull-request system. No developer may approve or merge their own change into production. For bespoke and custom software in the CDE, code reviews shall be documented and the results reviewed and approved by management prior to release (PCI DSS 6.2.3).
7. Dependency, Component and Patch Management
The Company shall maintain an inventory of bespoke and custom software and of all third-party and open-source components, including versions, to enable timely vulnerability management (PCI DSS 6.3.2 — SBOM). Newly identified vulnerabilities shall be assigned a risk ranking (PCI DSS 6.3.1) and remediated within the following service levels from the date a fix becomes available: critical vulnerabilities within 30 days; high vulnerabilities within 90 days; medium and low vulnerabilities on a risk-based schedule defined by the security team. Vendor and open-source security advisories shall be monitored continuously, and end-of-life or unsupported components shall be upgraded or replaced. Emergency patches for actively exploited (zero-day) vulnerabilities shall be applied on an expedited basis through the emergency change process.
8. Separation of Development, Test and Production Environments
Development, test/staging, and production environments shall be separated and secured to reduce the risk of unauthorised access or changes to the production environment (A.8.31; PCI DSS 6.5.3). Controls include: (a) logically and, where appropriate, physically separated environments with distinct credentials and access controls; (b) separation of duties between the personnel who develop code and those who deploy it to production; (c) development tools, source code, compilers, and non-production build artefacts kept out of the production environment; (d) restricted, logged, and least-privilege access to production. Direct developer access to production is prohibited except through controlled, audited break-glass procedures.
9. No Production Data in Test or Development
Live production data — in particular personal data, cardholder data, and other Restricted-classification information — shall not be copied into or used within development or test environments (A.8.33; PCI DSS 6.5.5). Test and development shall use anonymised, masked, tokenised, or synthetically generated data. Where the use of production data is unavoidable, it shall be treated as an exception subject to prior authorisation, equivalent security controls to production, minimisation, logging, and secure deletion when no longer required. Sensitive test information shall be protected and removed from test systems immediately after testing is complete.
10. Change Management and Approval
Changes to infrastructure, data, software, and procedures shall be authorised, designed, developed or acquired, configured, documented, tested, approved, and implemented in a controlled manner (SOC 2 CC8.1). Every production change shall have: (a) a documented change request describing purpose and impact; (b) evidence of testing in a non-production environment; (c) formal approval by an authorised person other than the implementer; (d) a rollback / back-out plan; and (e) an audit trail. Emergency changes may bypass the standard approval sequence but shall be documented and retrospectively reviewed and approved within a defined timeframe.
11. Outsourced and Third-Party Development
Where software development is outsourced, Acme Technologies Pvt Ltd shall direct, monitor, and review the activities of the supplier to ensure security is maintained across the supply chain (A.8.30). Contracts with development partners shall require: (a) adherence to this Policy and the Company's secure coding and testing standards; (b) rights to review threat models, code, and security test results; (c) evidence of secure coding training and vulnerability remediation; (d) acceptance security testing before deliverables are accepted; and (e) ownership and escrow arrangements for source code where appropriate. Outsourced code is subject to the same review, testing, and approval gates as internally developed code.
12. Roles, Responsibilities and Compliance
The Policy Owner (Vikram Patel ) is responsible for maintaining this Policy and the secure development programme. Engineering managers are accountable for enforcing security gates within their teams; developers are responsible for writing secure code and remediating findings; and the application security function operates the tooling and validates compliance. Suspected vulnerabilities shall be reported to appsec@company.com . Compliance with this Policy is mandatory; violations may result in disciplinary action. Adherence shall be verified through pipeline controls, code-review records, and internal audits conducted at least annually.
13. Policy Review and Update
This Policy shall be reviewed at least annually, and additionally following significant changes to the technology stack, the threat landscape, applicable standards (ISO 27001, SOC 2, PCI DSS), or after a material security incident. Changes must be approved by the Policy Owner and management and communicated to all affected personnel. The next scheduled review date is [Review Date].
This Secure Development Policy has been approved by the management of Acme Technologies Pvt Ltd and is effective from [Effective Date].
CEO / Chief Technology Officer
CEO / CTO name (for management statement)
______________________
Policy Owner (Head of Engineering / CISO)
Vikram Patel
______________________