Secure Development Policy
The purpose of Secure Development Policy is to specify procedures for ensuring security is part of the product development life cycle.
2. Scope and Applicability
Secure Development Policy applies to all the software that are developed by
3. Execution Responsibilities
along with Information Security Manager (ISM) is responsible to execute and implement physical and logical access control procedures mentioned in this document.
4. Secure Development Policy
4.1 Development lifecycle4.1.1 All product developments go through the following phases. Rules for the development of software and systems shall be established and applied to developments within the organization.
d) Testing in SIT and UAT
e) Deployment in production
4.1.2 Planning, Initiation/Requirements Analysis Phase
a) Product manager identifies the business problem and writes a PRD after user interviews and feature validation. Next comes project scheduling, capacity planning, cost estimation, and feasibility assessment along with the engineering team.
b) Any Customer data at rest is encrypted as per the Encryption method defined in the cryptographic controls policy.
a) Developers begin the actual development of the product after they understand the requirements of the end-users. Security considerations are taken into account regarding the sensitive data of the users.
b) Changes to systems within the development lifecycle shall be controlled by the use of formal change control procedures.
a) Dedicated QA team conducts risk assessments and tests for the security and functionality of the system.
b) Testing environments, SIT and UAT, are only available via VPN access.
c) Test data shall be selected carefully, protected and controlled
a) Production environment only available via VPN access.
b) Only select senior backend developers have access to production environments.
4.1.6 Security and protection over public networks
a) Customer data is protected in accordance with the access controls defined and in line with the requirements defined in the PRD.
b) Endpoints are always authenticated to ensure authorized access and happens over secure SSL connection.
4.1.7 Documented operating procedures Operating procedures shall be documented and made available to all users who need them.
4.1.8 Change Management Changes to the organization, business processes, information processing facilities and systems that affect information security shall be controlled.
4.1.9 Capacity Management The use of resources shall be monitored, tuned and projections made of future capacity requirements to ensure the required system performance.
4.1.10 Separation of development,testing and operational environments Development, testing, and operational environments shall be separated to reduce the risks of unauthorized access or changes to the operational environment.
4.1.11 Installation of software on operational systems Procedures shall be implemented to control the installation of software on operational systems.
4.1.12 Information security requirements analysis and specificationThe information security related requirements shall be included in the requirements for new information systems or enhancements to existing information systems
4.1.13 Securing application services on public networksInformation involved in application services passing over public networks shall be protected from fraudulent activity, contract dispute and unauthorized disclosure and modification.
4.1.14 Protecting application services transactions Information involved in application service transactions shall be protected to prevent incomplete transmission, mis-routing, unauthorized message alteration, unauthorized disclosure, unauthorized message duplication or replay.
4.1.15 Technical review of applications after operating platform changesWhen operating platforms are changed, business critical applications shall be reviewed and tested to ensure there is no adverse impact on organizational operations or security.
4.1.16 Restrictions on changes to software packages Modifications to software packages shall be discouraged, limited to necessary changes and all changes shall be strictly controlled.
4.1.17 Secure system engineering principles Principles for engineering secure systems shall be established, documented, maintained and applied to any information system implementation efforts.
4.1.18 Secure development environment Organizations shall establish and appropriately protect secure development environments for system development and integration efforts that cover the entire system development lifecycle.
4.1.19 Outsourced development. The organization shall supervise and monitor the activity of outsourced system development.
4.1.20 System security testing Testing of security functionality shall be carried out during development.
4.1.21 System acceptance testing Acceptance testing programs and related criteria shall be established for new information systems, upgrades and new version
4.2 Do you have a Secure Development Policy?
5.1 Exceptions shall not be universal but shall be agreed on a case-to-case basis, upon official request made by the information owner. These may arise, for example, because of local circumstances, conditions or legal reasons existing at any point of time.
5.2 All exception requests shall be submitted to (CTO). These shall be submitted through an email and be approved by (CTO).
6.1 reserves all rights and is the exclusive owner of all intellectual property rights over this Policy document. This document shall not, either in part or in full, be reproduced, published, copied, displayed, distributed, transferred, stored into any media (such as hard disks, USB Drives, Pen Drives, Memory Cards, CDS, DVD’s), and/or captured or transmitted through by any means (such as electronic, digital, mechanical, photocopying, recordings, video and film or photographs and otherwise) by any person without prior consent from the ISM. This Policy and procedure document is available with ISM and/or any other forum as decided by the management of . Anything not specifically stated in this Policy and procedure document shall not be considered as implied in any manner.
6.2. For any clarifications related to this Policy and procedure document with respect to its interpretation, applicability, and implementation, please write to the ISMS team at dpo@.com
7.1. This policy and procedure is applicable to all the employees of the company who have access to and use the information assets and IT assets as listed in the Information Asset register which has been created for
7.2. Anyone found to have violated this policy will be subject to a process that will determine if the violation is just a process non-compliance issue that requires addressing or also includes ethical violations In the event of only the former, non-compliance could be issued by an internal auditor which would require corrective/preventive actions.
7.3. In the event of the latter, the ethical/regulatory concern process will be invoked to decide whether an ethical/security violation has occurred and to decide on appropriate disciplinary actions as per the Disciplinary procedure of
7.4. Management’s interpretation of the clauses in this procedure shall be final and binding. Management reserves the rights to alter or amend any clause in this document at any time as per its discretion.