Software Development Policy¶

Owner	Classification	Review Date	Status
CDO Office	Internal	April 2027	Active

Document Type: Policy | Owner: CISO | Classification: Confidential | Review Cycle: Annual

Field	Detail
Document #	SP-SDP-034
Version	V1.3
Issue Date	11/09/2025
Confidentiality Level	Class 2 (Private Data / Confidential)
Document Owner	Chief Technical Officer
Authorised By	Yassir Pasha

Document Creation¶

Field	Detail
Document #	SP-SDP-034
Document Title	Software Development Policy
Version	V1.3
Confidentiality Level	Class 2 (Private Data / Confidential)
Date Created	23/04/2021
Issue Date	11/09/2025
Document Owner	Chief Technical Officer
Author(s)	Simpaisa
Purpose	To ensure that Software Development is controlled as per policy
Authorised By	Yassir Pasha

Reviewed By Steering Committee¶

Name	Role
Yassir Pasha	Chief Executive Officer
Kamil Shaikh	Chief Operating Officer
Osama Hashmi	Chief Financial Officer
Bachir Njeim	Chief Strategy and Operations Officer
Saqlain Raza	Acting Chief Technology Officer
Rizwan Zafar	Chief Product Officer
Ahsan Hussain	Payment Channel Partnerships
Danish Abdul Hameed	Chief Information Security Officer
Shahroze Khan	Head of International Merchant Sales and Strategic Alliances
Noor Ali	Country Head Pakistan
Shoukat Bizinjo	Global Head of Regulatory Affairs & Regulatory

Change Control¶

Version	Date of Issue	Author(s)	Brief Description of Changes	Approved By
V1.0	28/04/2021	Rizwan Zafar	Initial release	Salim Karim
V1.1	07/02/2022	Rizwan Zafar	Annual review	Salim Karim
V1.2	02/02/2023	Rizwan Zafar	Annual review	Salim Karim
V1.3	10/10/2024	Syed Zubair Ahmed	Added section 3. Mandatory Security Practices for Development, 5. Continuous Improvement, 6. Recommendations for SSDLC Implementation, 7. Threat Modelling	Yassir Pasha
V1.3	11/09/2025	Simpaisa	Annual Review	Yassir Pasha

1 Introduction¶

The purpose of this Policy is to standardise software development for all enterprise-level centrally managed mission critical web applications and web services through the use of industry leading practices. These applications and services typically deal with sensitive data; therefore, adequate shielding of this data is required. Standardising the development approach and coding techniques for critical systems will ensure their maintainability, security, protection against cyber-attacks and accessibility, and assist the team in adhering to best practices.

This Policy applies to all employees (i.e., Developer, data scientist and quality assurance team etc.), consultants and/or contractors involved in the development or modification of enterprise-level centrally-managed mission critical applications that support Simpaisa. If any provision of this Policy is found to be inconsistent with the provisions of a collective agreement, the collective agreement will prevail, unless the Policy provision is required by law, in which case the Policy provision will prevail.

Simpaisa is providing digital payments and disbursement solutions. It is the responsibility of Simpaisa to make sure product development adheres to industry standards and compliance practices.

Best coding practice is a mandatory requirement for development and all DEV team members should be well aware of this. For this, the following are the mandatory requirements for the development team:

Team leads should share this document with newly joined developers.
Responsibilities of developer during probation period: review this document
Review development guide mentioned in this document

Simpaisa's systems and applications have been developed in accordance with Payment Card Industry Data Security Standards (PCI DSS) requirements, ISO 27001:2022, and industry best practices.

A process is established to identify security vulnerabilities, using reputable outside sources for security vulnerability information.

2 Software Development Life Cycle (SDLC)¶

2.1 Software Development Life Cycle (SDLC) Scrum Framework¶

A Scrum (also known as iteration or timebox) is the basic unit of development in Scrum. The sprint is a timeboxed effort; that is, the length is agreed and fixed in advance for each sprint — one month.

Each sprint starts with a sprint planning event in which a sprint goal is crafted and a sprint backlog emerges, containing intended work for the upcoming sprint. Each sprint ends with two events:

A sprint review (progress shown to stakeholders) — Meeting duration 2 hours
A sprint retrospective (identify lessons and improvements for the next sprints) — Meeting duration 2 hours

Scrum emphasises valuable, useful output at the end of the sprint that is really done. In the case of software, this likely includes that products are fully integrated, tested and documented, and potentially releasable.

2.1.1 Sprint Planning¶

At the beginning of a sprint, the scrum team holds a sprint planning event to:

Agree the sprint goal, a short description of what they forecast to deliver by sprint end, based on the priorities set by the product owner
Select product backlog items that contribute towards this goal
Form a sprint backlog by mutually discussing and agreeing on which items are intended to be done during that sprint

The maximum duration of sprint planning is two to three hours for a 4-week sprint. As the detailed work is elaborated, some product backlog items may be split or returned to the product backlog if the team believes they cannot complete that work in a single sprint.

2.1.2 Daily Scrum¶

A daily scrum in the computing room. This centralised location helps the team start on time.

Each day during a sprint, the developers hold a daily scrum with specific guidelines. All developers come prepared. The daily scrum:

is focused on inspecting progress towards the sprint goal
should happen at the same time and place every day
is limited (timeboxed) to fifteen minutes
is conducted however the team decides
may include others, though only developers should speak
may be facilitated by the Scrum Master
may identify impediments to progress (e.g., stumbling block, risk, issue, delayed dependency, assumption proved unfounded)
does not feature discussions
is NOT a "status report" or a means of updating progress charts

No detailed discussions should happen during the daily scrum. Once over, individual members can discuss issues in detail, often known as a 'breakout session' or an 'after party'. Blockers identified should be collectively discussed outside of the daily scrum with a view to working toward a resolution.

2.1.3 Sprint Review¶

Conducted at the end of a sprint, the team:

presents the completed work to the stakeholders (a.k.a. the demo)
collaborates with stakeholders on topics such as:
1. inviting feedback about the completed product increment
2. discussing the impact of incomplete work (planned or otherwise)
3. receiving suggestions for upcoming work (guidance of what to work on next)
4. Product Owners should see this event as a valuable opportunity to review and refine the product backlog with stakeholders.

Guidelines for sprint reviews:

Incomplete work should not be demonstrated; although stakeholders should be presented with product increments they will be receiving, they can also request to see work in progress if necessary. However, the team should only be prepared to show what has been done.
The recommended duration is two hours for sprint, with all stakeholders involved in the project.

2.1.4 Sprint Retrospective¶

At the sprint retrospective, the team:

reflects on the past sprint
identifies and agrees on continuous process improvement actions

Guidelines for sprint retrospectives:

Three suggested areas to consider in sprint retrospectives are:

What went well during the sprint?
What did not go well?
What could we do differently the next sprint?

The recommended duration is two hours for a two-week sprint (proportional for other sprint durations). The scrum master may facilitate this event, but their presence is not considered mandatory.

Although not originally a core Scrum practice, backlog refinement or grooming was added to the Scrum Guide and adopted as a way of managing the quality of product backlog items entering a sprint. It is the ongoing process of reviewing and amending/updating/re-ordering product backlog items in the light of new information.

Reasons for modifying the backlog and items within may include:

Larger items may be broken into multiple smaller ones
Acceptance criteria may be clarified
Dependencies may be identified and investigated
An item may require further discovery and analysis
Priorities may have changed; expected returns will now differ
Refinement means that items are appropriately prepared and ordered in a way that makes them clear and executable for developers for sprint planning.

The backlog can also include technical debt. This is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.

The backlog will include all change requests and new feature requests. During a sprint all backlog items will remain in backlog. It is the responsibility of the product owner to refinement of backlog, to ensure all items have a definition of done (Acceptance criteria).

2.1.6 Cancelling a Sprint¶

The product owner can cancel a sprint if necessary, and may do so with input from others (developers, scrum master or management). For example, recent external circumstances may negate the value of the sprint goal, so it is pointless in continuing.

When a sprint is abnormally terminated, the next step is to conduct new sprint planning, where the reason for the termination is reviewed.

2.2 Role and Responsibility¶

2.2.1 Product Owner¶

The product owner, representing the product's stakeholders and the voice of the customer (or may represent the desires of a committee), is responsible for delivering good business results. Hence, the product owner is accountable for the product backlog and for maximising the value that the team delivers. The product owner defines the product in terms of customer-centric outcomes (typically – but not limited to – user stories), adds them to the product backlog, and prioritises them based on importance and dependencies. A scrum team should have only one product owner.

Communication is a core responsibility of the product owner. The ability to convey priorities and empathise with team members and stakeholders is vital to steer product development in the right direction.

As the face of the team to the stakeholders, the following are some of the communication tasks of the product owner:

Define and announce releases.
Communicate delivery and product status.
Share progress during management meetings.
Share significant RIDAs (risks, impediments, dependencies, and assumptions) with stakeholders.
Negotiate priorities, scope, funding, and schedule.
Ensure that the product backlog is visible, transparent, and clear.

2.2.2 Developers and QA¶

The developers and QA carry out all work required to build increments of value every sprint.

The developers should not only be responsible for technical aspects but should also collaborate and contribute to finding better ways to deliver high-quality software and embrace continuous improvement. Furthermore, they are expected to actively participate in security practices and initiatives within the Secure Software Development Life Cycle (SSDLC).

The team is self-organising. While no work should come to the team except through the product owner, and the scrum master is expected to protect the team from distractions, the team are encouraged to interact directly with customers and/or stakeholders to gain maximum understanding and immediacy of feedback.

2.2.3 Scrum Master¶

Scrum is facilitated by a scrum master, who is accountable for removing impediments to the ability of the team to deliver the product goals and deliverables. The scrum master is not a traditional team lead or project manager but acts as a barrier between the team and any distracting influences.

The core responsibilities of a scrum master include (but are not limited to):

Helping the product owner maintain the product backlog in a way that ensures the needed work is well understood so the team can continually make forward progress
Helping the team to determine the definition of done for the product, with input from key stakeholders
Coaching the team, within the Scrum principles, in order to deliver high-quality features for its product
Educating key stakeholders and the rest of the organisation on Scrum (and possibly Agile) principles
Helping the scrum team avoid or remove impediments to its progress, whether internal or external to the team
Promoting self-organisation and cross-functionality within the team
Facilitating team events to ensure regular progress

3 Mandatory Security Practices for Development¶

Simpaisa places great importance on the following security practices for all development processes to safeguard sensitive data and ensure compliance with ISO 27001:2022 standards. All developers must adhere to the following mandatory security practices:

3.1 Secure Coding Practices¶

Developers must follow secure coding practices to minimise security vulnerabilities. These practices include but are not limited to:

Input validation to prevent injection attacks.
Output encoding to mitigate cross-site scripting (XSS).
Authentication and session management controls.
Regularly updating dependencies and libraries.
Implementing logging and monitoring practices to detect security incidents.

3.2 Code Review and Static Code Analysis¶

All code must undergo peer review and static code analysis before deployment. This process helps identify security vulnerabilities, coding standards violations, and potential bugs early in development.

3.3 Security Testing¶

Security testing should be conducted during each sprint, including:

Vulnerability assessments.
Penetration testing.
Security regression testing to ensure previously resolved vulnerabilities remain fixed.

3.4 Vulnerability Assessment and Penetration Testing (VAPT)¶

VAPT is a critical process at Simpaisa aimed at identifying and addressing security vulnerabilities. The process includes:

Regularly Scheduled VAPT: Conduct VAPT at least once per quarter or after significant changes to the application or infrastructure.
Third-Party Services: Engage reputable external vendors to perform VAPT, ensuring an unbiased assessment of security posture.
Internal Testing: Encourage developers to conduct internal penetration testing to identify vulnerabilities during the development phase.
Reporting: Document findings in a comprehensive report detailing vulnerabilities, potential impacts, and recommended remediation steps.
Remediation: Establish a process to prioritise and address vulnerabilities based on risk assessments, ensuring timely remediation before the next sprint.

3.5 Secure Deployment Practices¶

Deployments must follow secure practices to minimise risks, such as:

Using secure channels for deployment (e.g., HTTPS, SFTP).
Implementing access controls to restrict deployment access.
Maintaining a rollback plan in case of deployment failures.

3.6 Incident Response Planning¶

An incident response plan must be established to address potential security breaches. Developers must be trained to recognise security incidents and know how to report them promptly.

3.7 Training and Awareness¶

All team members must participate in regular security training and awareness programmes to stay informed about the latest security threats and best practices. This includes mandatory training sessions at least once every quarter, focusing on updates in secure coding practices, threat landscapes, and compliance requirements.

4 Continuous Improvement¶

Simpaisa encourages a culture of continuous improvement in all development practices. Feedback from stakeholders and team members will be used to refine processes, enhance security measures, and optimise product delivery. Regular retrospectives and reviews will be structured to identify gaps in compliance and security measures.

5 Recommendations for SSDLC Implementation¶

To strengthen the Secure Software Development Life Cycle (SSDLC) at Simpaisa, the following enhancements are recommended:

5.1 Integrating Security Early in the SDLC¶

Implement security assessments during the requirement gathering and design phases to identify potential vulnerabilities before development begins.
Encourage collaboration between security experts and development teams to incorporate security requirements directly into the backlog.

5.2 Continuous Security Training¶

Establish a formal training programme focused on SSDLC principles, secure coding practices, and the latest security threats, tailored for developers and QA teams.
Conduct regular workshops and knowledge-sharing sessions to promote security awareness and foster a security-first mindset across all teams.

5.3 Automated Security Testing¶

Integrate automated security testing tools into the CI/CD pipeline to identify vulnerabilities continuously as code is developed and deployed.
Employ tools for static and dynamic analysis, as well as dependency scanning, to catch issues early.

5.4 Enhanced Documentation Practices¶

Maintain detailed documentation of security practices, incidents, and resolutions to support continuous improvement and knowledge sharing.
Create a centralised repository for all security-related policies, procedures, and guidelines to ensure easy access for all team members.
Ensure thorough documentation of coding standards, practices, and compliance measures, making it available for audits and reviews.

6 Threat Modelling¶

Threat modelling is a structured approach to identifying, evaluating, and mitigating security threats during the software development process. It aims to anticipate potential security issues before they manifest in the product, allowing the team to address vulnerabilities early in the SDLC.

6.1 Threat Modelling Process¶

The threat modelling process involves the following steps:

Define the Assets and Boundaries: Identify critical assets (e.g., data, services, systems) and boundaries (e.g., trust boundaries between subsystems). These assets are crucial as they represent the targets of potential attackers.
Identify Potential Threats: Use established threat modelling frameworks like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) or PASTA (Process for Attack Simulation and Threat Analysis) to classify potential threats.
Analyse Attack Vectors and Weaknesses: Once threats are identified, analyse how they might be exploited by adversaries. This step may involve simulating attack scenarios and assessing possible attack surfaces, like entry points into the system.
Rank the Threats Based on Risk: Evaluate the likelihood and impact of each threat and prioritise them based on risk. High-risk threats should be addressed first. A risk assessment matrix can be used to guide prioritisation, taking into account factors like likelihood, impact, and mitigation cost.
Mitigate the Threats: Develop countermeasures to mitigate or eliminate threats. These countermeasures could include security controls, architecture changes, or specific coding practices. The team should ensure that each threat has a corresponding defence strategy that is applied before the product moves to the next phase of development.
Document and Review: Threat modelling documentation should be maintained and regularly reviewed to ensure that new threats are addressed, and past threats remain mitigated.

6.2 Integration with SSDLC¶

Threat Modelling will be conducted at the beginning of the design phase and revisited throughout the development process (during backlog refinement and sprint planning).
Threat assessments will be part of the sprint review sessions to ensure evolving threats are addressed during development iterations.

7 Development Environment¶

A test/development environment, separate from the production environment, must be used to test all software. If the network has network connectivity with the production network, access controls must be in place to enforce the separation.

Production data will not be used for testing and development purposes without being sanitised. Test personnel should make every effort to use mock data only for testing on non-production systems and software. If it is determined that production data must be used in testing, the Steering Committee must review and approve the business justification, the testing window will have as short a duration as possible, all PCI, ISO 27002, OWASP controls must be enforced on the systems under test, and the Technical Committee must be notified of test results, and verification that production data has been scrubbed after close of testing window.

All test data, custom application accounts, usernames and passwords must be removed at the conclusion of testing, and in all cases before software becomes active. All code promotion to the production environment will be accomplished by the System Administrators. Under no circumstances will the Development Department have full time read/write access to production applications or data. Under emergency situations developers may assist in troubleshooting utilising an Emergency ID described in the section of Information Security Team Responsibilities.

7.1 Secure Software Development Procedures¶

Design – Application components must be planned in a manner consistent with Development best practices, data and network security.
Development – Developers must consider all application vulnerabilities (i.e.: memory bound issues, privilege and access bypass, etc.).
QA Implementation – Implementation must not compromise security controls already in place, or introduce new vulnerabilities.
QA Testing – In addition to functional and efficiency testing, all security features of the application must be tested.
Documentation – All application feature and implementation documentation must include direction on proper security configurations.
Production Implementation – Implementation must not compromise security controls already in place, or introduce new vulnerabilities.
Production Testing – In addition to functional and efficiency testing, all security features of the application must be tested.
Maintenance – All future application maintenance should not compromise security controls already in place, or introduce new vulnerabilities.
Code Changes – All future code changes must be reviewed by individuals other than the originating author. The reviewer must have adequate knowledge about code-review techniques and secure coding practices.

7.2 Java Based Development¶

In addition to the Development Life-Cycle security measures, special care should be given to Java-based applications. All Company developers will receive training on secure coding practices at least annually. Specifically, the following vulnerabilities must be considered and checked for during the Code Review and Testing phases:

Unvalidated Input
Malicious Use of User IDs
Malicious Use of Account Credentials
Broken authentication and session management
Cross-Site Request Forgery (CSRF)
Cross-Site Scripting
Buffer Overflows
SQL Injection and other Command Injection Flaws
Error Handling Flaws
Insecure cryptographic storage
Denial of Service
Insecure Configuration Management
Insecure Direct Object references
Insecure communication

All "high risk" vulnerabilities identified in the vulnerability identification process annually, and whenever significant modifications have taken place, all web-based applications will be put through an application specific penetration test. All custom code is to be reviewed by an organisation that specialises in application security or an application layer firewall in front of applications.

7.3 UAT Environment and Production Builds¶

Company uses GIT (Gitlab or Bitbucket) for code version control with relative branches for Master, State and dev. Before any branch is taken into production environment each new feature/bugfix build is taken into the staging branch for thorough QA testing and Code review conducted by Architect/Senior Developer. Only Company Chief Technical Officer is responsible for taking any build into the production environment once all relevant testing is complete by the Company and vendor.

7.4 Acknowledgment¶

All parties are subject to annual acknowledgement that they have read and understood the software development and secure software development policy and procedure. Where possible this task will be completed electronically but in certain circumstances this may need to be in writing.

8 Software Development and Security Development Training¶

The level of training required and the frequency of it will depend on the interested party involved. It is a requirement that all parties must have security awareness training upon employment and annually. However, this will vary according to the party's role and their level of contact with cardholder data or any other application in use of Simpaisa.

Interested Party	Training Areas	Methods	Frequency
Executive Management	Software development and Security development Awareness; Information security strategy	Board briefings; CISO 1-1 with Executive	Yearly
Departmental Management	Software development and Security development awareness; Security requirements for new IT systems; Review of risks and issues; Reviews of security breaches	Software Development team; Specific agenda items at Senior Management Team Meetings; IT Change Advisory Board	Half-Yearly
IT Users	Software development and Security development; Communication of Information Security Policy; Ad-hoc reminders when important events occur e.g. breaches; Warnings and awareness	Newsletters; Surveys; E-Zine articles; Emails	Quarterly
IT Staff	Software development and Security development Policy	Briefings; Project meetings	Half-Yearly