1.  Objective

The purpose of this policy and procedure is to define and implement robust, secure, and standardized practices throughout the software lifecycle, including design, development, testing, deployment, and maintenance.

2.  Scope

The Software Development Policy applies to all software development activities conducted by employees, contractors, and third-party vendors on behalf of our organization. It encompasses the entire software development lifecycle, including planning, design, coding, testing, deployment, maintenance, and retirement of software applications and systems. This policy applies to all software development projects, regardless of the platform, programming language, or development methodology employed.

3.  Provisions

3.1  Requirement Specification and Design

3.1.1  Iterative Backlog Management

Requirements shall be managed as a dynamic Product Backlog rather than a static Business Requirements Specification Document (BRD). Requirements should be captured as User Stories (e.g., As a [user], I want [feature], so that [value]) within a secure, centralized Agile management tool. The IT Development team and requesting party shall meet regularly for Backlog Refinement to provide estimates, identify security controls, and validate logic. The Product Owner (or Process Owner) is accountable for prioritizing the feature backlog based on business value and ROI. ELT is responsible for approval of new requirements.

3.1.2  Definition of Ready (DoR) and Iterative Approval

The requirement for a single, comprehensive sign-off prior to any development is replaced by an iterative Definition of Ready (DoR). Development may proceed on specific User Stories or features once they meet the DoR, which must include validated business logic and agreed-upon security requirements. Requirements are considered approved when the relevant stakeholders (Product Owner, Security, and Lead Developer) move the item to a Ready or Approved state within the collaboration tool.

3.1.3  Continuous Security Integration

Security is to be integrated directly into Sprint Planning or Refinement sessions. Security requirements such as (but not limited to) data masking, authentication and RBAC, data isolation, encryption, and access control should be treated as Security Stories or added to the Definition of Done (DoD) to ensure they are built and verified incrementally.

3.1.4 Privacy Impact Assessment (PIA) for Data-Handling Automations

Any automation script, workflow, or system feature that collects, processes, exports, or distributes personal data (including employee PII, performance data, quiz/assessment results, or health records) must undergo a Privacy Impact Assessment (PIA) and Security Review before deployment to any environment.

The PIA must be completed jointly by the Development Team and the Security Team, and must address:

a)  Data Classification: Identify the sensitivity level of each data element handled by the automation (e.g., PII, PHI, performance-sensitive data).

b)  Data Minimization: Confirm the output contains only the minimum fields required for the intended purpose. Raw exports with individual-level identifiers must never form part of a distribution output unless explicitly approved.

c)  Access Scope: Define who may trigger, view, and receive output from the automation, and validate against RBAC rules.

d)  Output Format Review: Confirm that any report, file, or email attachment generated by the automation is limited to pre-approved, sanitized summary formats.

e)  Dual Approval Gate: PIA sign-off requires the Lead Developer AND the Security Team (or designated Privacy Officer) before deployment.

Scripts or automations already in production that were deployed without a PIA must be retrospectively reviewed within 90 days of this policy's effective date and remediated accordingly. These items must be logged in the IT Security Risk Log.

3.1.5 Dynamic Documentation and Auditing

The policy requires retaining meeting minutes and sign-off forms for 3 years to demonstrate compliance. Utilize the audit trails, comment history, and status changes within Agile management tools as the secure, auditable repository. Digital approvals within the tool should serve as the formal sign-off to maintain velocity while meeting ISO 27001 evidence requirements.

3.2  Segregation of Duties

The following matrix provides a general overview of the different roles and responsibilities per stage which provides a check and balance on approval of access and decision making. RASCI: R=Responsible, A=Accountable, S=Supportive, C=Consulted, I=Informed.

3.3  Development and Secure Coding

Development should be guided by the following items as applicable or feasible. Any exception needs a proper IT security Risk review and must be agreed with the process owners, Security team, Developers, IT Director and/or VP IT.

3.3.1  Separation of Environments

Development, Testing, and Production environments must be logically and/or physically separated. No production data (PII/PHI) shall be used in non-production environments without explicit masking or anonymization. Exceptions are only allowed when it is not possible and when approved by Process Owners, Managers, Security Team, and IT Director.

3.3.2  Least Privilege Access

Access to source code repositories and deployment pipelines must be granted based on the principle of least privilege and protected by Multi-Factor Authentication (MFA).

3.3.3  Version Control

All source code, configurations, and infrastructure-as-code (IaC) must be maintained in a centralized version control system with an immutable audit trail when applicable.

3.3.4  Input Validation and Output Encoding

All data received from untrusted sources must be validated against a strict allow-list. Data sent to the browser or other systems must be encoded to prevent injection attacks (SQLi, XSS).

3.3.5  Static Analysis (SAST)

Automated code scanning must be integrated into the CI/CD pipeline if applicable. Critical and High-severity vulnerabilities must be remediated before the code can be merged.

3.3.6  Software Composition Analysis (SCA)

All third-party and open-source dependencies must be scanned for known vulnerabilities (CVEs) and licensing risk if applicable.

3.3.7  Dynamic Analysis (DAST)

Functional applications must undergo dynamic scanning in a staging environment to identify runtime vulnerabilities when applicable.

3.3.8  Automated Pipelines

Manual deployments to production are discouraged to ensure consistency and prevent shadow changes.

3.3.9  Data Output and Dissemination Controls [NEW]

Any automation, script, or system that generates output files or data extracts intended for distribution must comply with the following controls:

a)  Output Scope Restriction: The output scope must be enforced at the code level. Scripts must never rely on manual file manipulation (e.g., manually hiding/unhiding spreadsheet tabs) to limit what data is exported. Scope restriction must be programmatic.

b)  Approved Output Template: A pre-approved, version-controlled output template must be defined for each recurring data dissemination process. The template must specify: permitted fields, aggregation level (summary vs. individual), and authorized recipients.

c)  No Raw PII in Distribution Files: Files containing individual-level identifiers (Full Name, Employee ID, Email, individual answers/scores) must never be included in distribution emails or shared drives accessible to non-authorized roles. Dissemination must use summary or aggregate formats only, unless a specific documented and approved business justification exists.

d)  Pre-Send Checklist: A pre-dissemination checklist must be completed and retained before sending any report or data export, covering: (1) output format verification, (2) recipient list validation, and (3) Security/Privacy Officer sign-off for any output containing personal data.

e)  Dual Approval for PII-Containing Outputs: Any dissemination of outputs that include personal data fields requires dual approval — from the IT Lead and the Security Team or Privacy Officer — prior to distribution.

3.3.10  Code Review Process

General Process: Once a developer believes their code is ready for review, they create a pull request (PR) against the target branch. Automated tools will scan the code before manual review when applicable. At least one peer, but preferably two, reviews the PR in detail. Feedback and required changes are provided, and the PR is approved and merged once reviewers are satisfied.

Automated Review includes: Static Code Analysis (SonarQube, ESLint or similar), Code Coverage tools (Codecov, Coveralls), Build and Test Automation in CI/CD, and Security Scans (Snyk, Dependabot) — all where applicable.

Review Focus Areas: Logic correctness; adherence to coding standards; potential performance bottlenecks; scalability and maintainability; security concerns; code clarity and documentation.

Exceptions: Rare exceptions due to urgent fixes must be discussed and approved by process owners or manager and the Security Team. Exception requests must be documented in the IT Security Risk Log and include: Justification, Risk Level, Systems/Modules Affected, and Compensating Controls. Any code merged under an exception must undergo a retrospective review within 48 hours of deployment.

Data Automation Script Review: All scripts and automations that process, export, or distribute personal or sensitive data are subject to mandatory manual peer code review regardless of the author's seniority. The peer review must specifically validate: (1) output scope restriction is enforced programmatically with no reliance on manual steps, (2) no PII field references that exceed the approved output template, and (3) recipient and distribution logic is correct and restricted to authorized roles.

3.3.11  Technical Documentation

The technical documentation must include at minimum: Overview, Process Owner, Architecture Diagram, Flow Hierarchy, Dependencies (Licenses, Environment, Access, Service Account, Authentication), Security and Access Control (e.g. Data Masking Strategy, Data Integrity Controls, Input Validation, Encryption at-rest and in-transit), Exception Handling Strategy, Logging and Monitoring, Testing Strategy,Version and Document Control.

Access to the technical documentation is restricted to authorized personnel only: Application Support Team, Development Team, Security, and the Delivery Manager. Documentation shall be reviewed and approved by the Delivery Manager before finalization or updates.

Data Dissemination Specification: Technical documentation for any automation or system that generates output files for distribution must include a dedicated Data Output and Dissemination section covering: (1) approved output format and permitted fields, (2) data classification of each output field, (3) authorized recipient roles, (4) pre-dissemination approval requirements including dual-approval if PII is involved, and (5) reference to the applicable Privacy Impact Assessment.

3.3.12  Acceptance, Continuous Validation and Definition of Done

Acceptance shall occur iteratively at the conclusion of each Sprint. The system shall be validated against the Definition of Done (DoD) and specific Acceptance Criteria defined for each User Story. The three layers of validation (Functional led by Product Owner, Technical led by Engineering, and Governance oversight) shall be integrated into the lifecycle of each Sprint.

Formal UAT is satisfied upon the Closing of a Sprint or the Approval of a User Story within the Project Management Tool (e.g., Jira, Azure DevOps), provided that: Acceptance Criteria for each story are marked as met; automated test logs and security scan results are linked to the build/release when applicable  and the Product Owner provides digital approval within the tool.

Data Output Compliance Checklist (added to the DoD for any feature involving data export, reporting, or dissemination):

i.    Privacy Impact Assessment completed and signed off (for features handling personal data).

ii.   Output template reviewed, documented, and version-controlled.

iii.  Output scope restriction is enforced programmatically — no manual data manipulation steps in the distribution workflow.

iv.   Pre-dissemination checklist documented and attached to the User Story in the project management tool.

v.    Recipient list validated against RBAC and least-privilege principles.

vi.   Dual-approval sign-off obtained from IT Lead and Security/Privacy Officer for any PII-containing output.

3.3.13  Outsourced Development

The company shall supervise and monitor the activity of all outsourced system development using all relevant and applicable information in this document. NDAs must be signed by both parties prior to discussion of any critical design or information. This policy should be forwarded, agreed to, and signed off by the outsourced developers.

Outsourced Developers/Vendors must follow these requirements: (a) live, personal, or sensitive production data must not be used for development or testing — only anonymized or dummy data is permitted; (b) all source code must be handed over using an approved source control system upon project completion; (c) any security incidents or data breaches must be reported immediately; (d) access is granted with the principle of least privilege; (e) their development process must comply with all security requirements in Section 3.1; (f) secrets management must follow approved secure methods — hardcoding of secrets is strictly prohibited; (g) their code is subject to Code Review approved and monitored by internal Lead Developers and the Security Team.

Infinit-O reserves the right for the Security Team to conduct security audits, penetration tests, and vulnerability scans on the vendor's deliverables at any point during the contract.

3.4  Production Change Management

Implementation plans should include a Risk Assessment for potential effects on confidentiality, integrity, and availability. A system owner must be identified to handle maintenance and disposal. Backup strategy, rollback plan, and business continuity plan must be drawn into the project plan and approved by the system owner per the Change Management policy. Changes must be documented through a Change Request per the Change Management policy.

3.5  Maintenance Phase

Appropriate backup and recovery setup should be utilized during maintenance. Bugs discovered in software may impact confidentiality, availability, or integrity and should be tested and resolved at the earliest opportunity. Any planned or unplanned Operating System changes require a security and functional capability review prior to implementation, submitted as a Change Request. Application vulnerability tests must be conducted regularly. There should be at least two developers knowledgeable about the system (lead and backup developer) to allow better transition and knowledge retention.

3.6  Production Monitoring and Incident Management

The Applications support team  must manage continuous monitoring, tracking system performance, bot executions, and failures. They are to detect issues, troubleshoot, and coordinate resolution. The Operations Team shall escalate the incident to the Process Owner when first-line troubleshooting has been exhausted or when the root cause is outside operational control. Escalation notifications must include a clear subject line, summary of issue and impact, diagnostic evidence, and a request for acknowledgment per SLA.

Any data overexposure incident — where an automation, script, or system generates or distributes output containing personal data beyond its approved scope — shall be treated as a security incident and must be reported immediately.

Reporting: Any employee, contractor, or third party who discovers or suspects a data overexposure incident must report it immediately to the IT Helpdesk via email at it.helpdesk@infinit-o.com, copying the IT Director (Security Head), or by calling the IT Helpdesk hotline at +63 8626 3866. The report must include: description of the incident, date and time of discovery, affected systems and assets, and potential impact. These incidents will typically be classified as Moderate or Critical severity depending on the nature of the data exposed and the breadth of unintended recipients.

Once reported, all subsequent response, escalation, notification, documentation, and postmortem activities shall follow the Incident Response Policy (CPP-IT-0314), including the applicable severity-based response timelines and the roles and responsibilities of the Incident Response Team. In addition to the standard incident response steps, the Development Team must submit a Corrective and Preventive Action (CAPA) plan addressing both technical remediation (per Section 3.3.9) and process remediation (per Section 4.3), and any code fix deployed under an emergency exception must undergo a retrospective code review within 48 hours of deployment (per Section 3.3.10).

3.7  Disposal Phase

Prior planning and actual decommissioning of systems must include removal of access rights and removal of software from PCs and servers. Security measures must be in place to enable safe removal of equipment and software, including low-level wiping of all hard disk drives and removal of any system-related access. During disposal, software code, data, and information may need to be archived per statutory requirements and internal/external audit requirements, overseen and signed off by system owners.

4.  Usage

4.1  Project / Feature Request Approval

New requirements need to be presented with their respective VP for initial approval, covering: objectives and features, process description (current and proposed), workflow diagrams, benefit analysis, and man-hours saved/value to business. If approved, the request is forwarded to the IT Development team for prioritization. The IT Development team will provide estimates, identify security requirements, and propose recommendations. For internal requirements, approval and prioritization will be decided by the ELT. For client requirements, projects will only proceed after contract approval by Infinit-O and the client.

4.2  System Environments

Development Environment: Serves as the primary workspace for coding, implementation, experimentation, debugging, and initial testing. Access is restricted to authorized developers, DevOps engineers, and relevant security personnel. Principle of least privilege is enforced; MFA is required.. No direct access between Development and Production. Sensitive credentials managed via secure vaults — never hardcoded or committed to version control. Only anonymized, generated, or seeded test data is permitted — live/production data is prohibited.

User Acceptance Test (UAT) Environment: Once development is complete, UAT is conducted based on the specification. If there are bugs or UAT fails, the developer will fix the issue per an agreed timeline. UAT will be satisfied as per the provisions under System Acceptance Test.

Production Environment: Once UAT passes, system developers will deploy based on agreed items. Newly developed systems and features include implementation plans. Bug fixes are rolled out per agreed timelines. A Service Account must be used for automation tasks — Personal IDs must not be used. Responsibility for automation post-go-live transfers to the Application Support Team. The Runbook/Documentation File must include: Process Name, Bot Name(s), Connection Details, Bot Owner, Credentials, Credential Expiry Time, User and Technical Documentation, Known Errors and Resolutions, Path Location, Error Logs and Audit Logs.

4.3  Data Dissemination Standard Operating Procedure

Any recurring process that involves distributing reports, data extracts, or analysis outputs derived from personal or performance data must be governed by a formally documented SOP. 

Each SOP must include at minimum:

a)  Process Name and Owner: Identify who is responsible for executing and overseeing the dissemination.

b)  Approved Output Format: Specify the exact fields and level of aggregation permitted in the output (e.g., summary scores only, no individual-level identifiers).

c)  Data Classification of Output: Label each output field per the organization's data classification standard.

d)  Authorized Recipient Roles: Define which roles are permitted to receive each type of output. Distribution to non-authorized roles requires explicit approval from the Security Team and relevant Process Owner.

e)  Pre-Dissemination Checklist: A documented checklist to be completed before each distribution event, covering: output format verification, recipient list validation, and dual-approval sign-off for PII-containing outputs.

f)  Frequency and Trigger: Specify when dissemination occurs and what triggers it.

g)  Retention and Access Control: Define how long distribution artifacts (emails, attachments, shared files) are retained and who may access them post-distribution.

Existing recurring dissemination processes that currently lack a documented SOP must be identified and documented within 60 days of this policy's effective date.

5.  Responsibilities

Senior Leadership Team are responsible for ensuring that staff and managers are aware of Infinit-O IT security policies and that they are complied with. Managers must ensure staff have the relevant knowledge concerning security of information and systems which they develop or maintain. Staff involved within the systems development lifecycle must be aware of their responsibilities toward security. Designated owners of systems must ensure that staff have been made aware of their responsibilities toward security.

Privacy and Data Output Accountability: The Security Team (or designated Privacy Officer) is accountable for reviewing and approving the Privacy Impact Assessment for any new automation or system feature that handles personal data. The Lead Developer is responsible for ensuring all data output scripts comply with Section 3.3.9 before deployment.is accountable for ensuring all data dissemination SOPs (Section 4.3) are documented and enforced. Process Owners are accountable for validating that the output format and recipient list for their respective processes is accurate and current.

6.  Frequency

BRD/DOR and/or DOD: as the need arises. 

Non-Disclosure Agreement (NDA): as the need arises.

User Acceptance Test (UAT): as per agreement.

Privacy Impact Assessment: required prior to each new deployment or material change of a data-handling automation or script.

7.  Distribution

IT Team | Software Development Team | Managers/Directors | VPs

8.  References

ISO 27001:2022 Controls (Annex 5.15, 5.18, 5.33, 5.34)

Control of Records Policy

Change Management Policy

QA/UAT Responsibility Framework

Philippine Data Privacy Act (RA 10173)