Ligala Tech Pte Secure Software Development and Change Management Policy

Table of Contents

• 1. Purpose
• 2. Scope
• 3. Policy Statement
• 4. Roles and Responsibilities
• 5. Policy Requirements
• 6. Implementation Guidance
• 7. Monitoring, Evidence, and Compliance
• 8. Exceptions
• 9. Review and Maintenance
• 10. Related Standards

1. Purpose

This policy establishes mandatory controls for secure software development and change management at Ligala Tech Pte. As a legal technology company serving clients who depend on confidentiality, integrity, and availability of software services, Ligala Tech must ensure that application code, infrastructure configurations, and operational changes are designed, reviewed, tested, approved, and deployed in a controlled manner. The policy reduces the likelihood that vulnerabilities, misconfigurations, unauthorized changes, or privilege escalation paths are introduced into systems that may process client-sensitive, privileged, or personal data.

This policy supports Ligala Tech’s commitment to trustworthy service delivery and predictable change execution. Because the organization is small, with limited personnel and a high reliance on a small number of systems and vendors, secure development and disciplined change control are essential to prevent single points of failure and avoid informal releases that bypass review. The policy also helps ensure that security is built into the software delivery lifecycle rather than applied after deployment.

This policy is intended to align development and operational practices with recognized expectations for secure development and controlled change management, including ISO 27001 and Singapore Personal Data Protection Act (PDPA) obligations. It defines the minimum controls required to protect the company’s applications, cloud services, infrastructure, and supporting tools from avoidable security risks.

2. Scope

This policy applies to all Ligala Tech Pte employees, contractors, interns, temporary staff, and third-party service providers who design, build, test, approve, deploy, administer, or support software and infrastructure on behalf of the organization. It applies equally to production and non-production environments where the change could affect security, availability, confidentiality, privacy, or legal service delivery.

The scope includes custom software, scripts, APIs, databases, infrastructure-as-code, cloud resources, authentication and access controls, network configurations, CI/CD pipelines, logging settings, and endpoint or server hardening changes. It also covers changes made through direct console access, command-line tools, configuration management, or vendor-managed portals where the change can affect services or data. For a legal technology provider, this breadth is necessary because even small configuration updates can expose client data or disrupt evidence handling, document workflows, or authenticated access.

This policy applies to all lifecycle stages from initial design through deployment, maintenance, emergency remediation, and retirement. It governs both permanent changes and temporary changes that may later become standard practice. Where a third-party vendor or managed service performs changes on Ligala Tech’s behalf, the organization remains accountable for ensuring that the vendor follows requirements consistent with this policy.

3. Policy Statement

Ligala Tech Pte shall require secure development practices and controlled change management for all application and infrastructure changes. No code, configuration, infrastructure, or access-related change may be deployed to production unless it has been developed using approved secure coding practices, reviewed for security and correctness, tested in an appropriate environment, and authorized through the defined change approval process.

All changes must be traceable from request to implementation, including the business justification, risk assessment, reviewer identity, test evidence, approval decision, deployment record, and post-change validation. Changes affecting confidentiality, personal data, authentication, authorization, encryption, logging, or network exposure require heightened scrutiny and may not bypass security review except under a formally documented emergency process approved by an authorized role.

Ligala Tech shall integrate security into the software delivery lifecycle in a manner proportionate to its size and risk profile. Because the organization is small, responsibilities may be combined in a few individuals, but no person may approve their own high-risk change without independent review, and production access must remain restricted to authorized personnel only. Security controls must be practical, repeatable, and evidenced so that the organization can demonstrate both internal discipline and alignment with legal and contractual obligations.

4. Roles and Responsibilities

• Managing Director / Executive Sponsor: Approves this policy, ensures resources are available for secure development and controlled change practices, and reviews material policy exceptions and high-risk issues that could affect client trust or regulatory exposure.
• Information Security Owner or Designated Security Lead: Defines minimum security review standards, maintains the secure coding checklist, oversees vulnerability and exception management, and verifies that security controls are embedded in the development and release process.
• Development Lead or Engineering Lead: Ensures developers follow secure coding standards, code review requirements, branching practices, and testing obligations; confirms that changes are technically complete before release requests are submitted.
• Change Approver or Release Manager: Coordinates change assessment, confirms evidence is present, ensures required approvals are collected, and authorizes or rejects production deployments based on completeness and risk.
• Developer / Engineer: Implements changes securely, performs self-review, documents testing, remediates findings, and provides accurate change records and deployment notes.
• Quality Assurance / Tester, where assigned: Executes or validates functional, regression, and security-relevant tests, records results, and reports defects or risk issues before release.
• System Administrator / Cloud Administrator: Implements infrastructure and access changes only through approved change records, validates post-change functionality, and preserves logs or deployment artifacts.
• Data Protection Representative or Privacy Owner: Reviews changes that may affect personal data processing, retention, transfer, or access controls, and confirms PDPA-related implications are addressed before release.
• Third-Party Vendor Manager or Contract Owner: Ensures external providers follow agreed security and change controls, obtains supporting evidence, and escalates noncompliance or service risks.

5. Policy Requirements

• Secure coding standards must be documented, maintained, and used for all new code and material code modifications; the Development Lead owns this control; it is reviewed at least annually and whenever major technology changes occur; evidence includes the approved standards document and developer attestation or training records.
• All code changes must undergo peer review before merge to the main branch; the Developer owns the submission and a second qualified reviewer owns the review; this occurs for every change except approved emergency fixes; evidence includes pull request records, reviewer comments, and merge approvals.
• Security-relevant changes must include a threat or risk review proportional to the change scope; the Information Security Owner owns the review and the Developer provides inputs; this occurs for each change affecting authentication, authorization, encryption, data handling, or exposed interfaces; evidence includes risk notes or a completed security checklist.
• Static analysis, dependency scanning, and secret scanning must be performed on code changes before release where tooling is available; the Development Lead owns configuration and the Developer resolves findings; this occurs on every build or release pipeline execution; evidence includes scan reports and remediation tickets.
• Functional, regression, and security-focused testing must be completed in a non-production environment before production deployment; the QA role or Developer, where no QA role exists, owns execution; this occurs for each release; evidence includes test cases, results, and defect resolution records.
• Production releases must require approval by an authorized Change Approver who is independent of the change author for high-risk changes; the Change Approver owns authorization; this occurs for each production release; evidence includes approved change tickets or release records.
• Emergency changes must be limited to incidents that materially affect service availability, security, or legal obligations, and must receive post-implementation review within five business days; the Change Approver and Information Security Owner jointly own review; this occurs only when normal approval timing would cause greater harm; evidence includes emergency change justification, retrospective review, and follow-up actions.
• Infrastructure, network, access, and configuration changes must follow the same review and approval controls as application code changes; the System Administrator owns implementation and the Change Approver owns authorization; this occurs for every change; evidence includes infrastructure-as-code review records, configuration diffs, and deployment logs.
• Privileged access used for deployment or system changes must be limited, time-bound, and separately approved where possible; the System Administrator or IT Owner owns enforcement; this occurs continuously; evidence includes access logs, access requests, and privileged session records.
• Changes to logging, monitoring, retention, or data access pathways that may affect PDPA compliance must be reviewed by the Data Protection Representative before release; the Data Protection Representative owns that review; this occurs whenever personal data processing may be affected; evidence includes privacy review notes and approval in the change record.
• Rollback or backout plans must be defined for every production change and validated for critical releases; the Developer or System Administrator owns the plan; this occurs for each release; evidence includes documented rollback steps and post-deployment validation records.
• Production deployment must be performed from approved repositories or automated pipelines rather than ad hoc manual edits, except during approved emergency response; the Engineering Lead owns process enforcement; this occurs for all standard releases; evidence includes pipeline logs, deployment records, and restricted-console access records.
• Source code, configuration files, and deployment artifacts must be version controlled and traceable to an approved change request; the Developer owns traceability and the Change Approver verifies it; this occurs for every change; evidence includes commit hashes, ticket references, and artifact versions.

6. Implementation Guidance

Ligala Tech should implement this policy through a lightweight but disciplined change workflow suited to a small organization. A practical approach is to use a ticketing system and version control platform as the system of record for each change. Each change should begin with a request describing the purpose, affected systems, risk level, testing plan, rollback plan, and release window. For smaller teams, a single ticket can capture both engineering and approval evidence, provided the required fields are consistently completed.

Secure development should be embedded into daily engineering practice. Developers should use branch protection, mandatory pull request reviews, and automated checks in the continuous integration pipeline. The organization should maintain a secure coding checklist covering authentication, authorization, input validation, error handling, logging, cryptography, and secrets management. Where open-source or third-party libraries are used, dependency updates should be screened for known vulnerabilities and licensing concerns before adoption.

Change management should distinguish routine, standard, and emergency changes. Routine changes are those with known patterns and low risk, but they still require testing and approval. Standard changes may follow a predefined template or release playbook. Emergency changes should be rare and tightly controlled, with afterward review to confirm the emergency classification was justified. For a legal technology company, this distinction matters because urgent fixes should not become a routine way to bypass scrutiny.

Operationally, the company should restrict production access and favor automated deployments from protected branches or tagged releases. Infrastructure changes should use infrastructure-as-code where practical, since it improves reviewability and rollback capability. Logging should capture who approved, who deployed, what changed, and when the change was verified. If a third-party service provider is involved, contracts or operating procedures should require evidence consistent with this policy before the service is accepted into production.

7. Monitoring, Evidence, and Compliance

Compliance shall be monitored through periodic review of change records, code review evidence, deployment logs, exception logs, and vulnerability scan results. The Information Security Owner or designated reviewer should sample changes regularly to confirm that approvals, testing, and rollback documentation are complete and that emergency changes were subsequently reviewed. For a small organization, a monthly sample combined with a quarterly management review is an effective baseline, while major releases and high-risk changes should receive immediate review.

Evidence artifacts must be retained in a searchable and tamper-resistant manner. Acceptable evidence includes pull request histories, code review comments, test execution reports, CI/CD logs, change tickets, deployment records, access logs, security scan outputs, and post-implementation validation notes. Where privacy impact is involved, evidence should also include the privacy review outcome and any required mitigations tied to PDPA obligations. These records should support internal audits, incident analysis, and customer assurance requests.

Compliance metrics should track the percentage of changes with complete approvals, the number of emergency changes, the rate of failed deployments, unresolved security findings, and the time taken to remediate critical issues. Escalation is required if a change is deployed without required approval, if a high-risk vulnerability is left unresolved past the agreed remediation window, if repeated emergency changes indicate a weak release process, or if production access is used outside approved procedures. Material or repeated noncompliance must be reported to the Managing Director and tracked to closure.

8. Exceptions

Exceptions to this policy are allowed only when adherence would create an unreasonable operational constraint and the residual risk is formally accepted. The requestor must document the control being bypassed, the reason, the duration of the exception, the systems affected, the compensating controls, and the specific business justification. Exceptions must be approved by the Information Security Owner and the relevant business or technical owner; high-risk exceptions must also be approved by the Managing Director.

All exceptions must be time-bound and should expire no later than ninety days unless a shorter period is appropriate based on risk. The exception record must include a review date, a mitigation plan, and an owner responsible for remediation. Expired exceptions may not be relied on as a standing practice, and repeated renewals require escalation and reassessment of whether the underlying process should be redesigned instead of exempted.

Exception approvals and renewals must be retained with the associated change or risk register record. During periodic policy review, the organization shall evaluate whether exceptions indicate process weakness, insufficient tooling, or resource constraints. Exceptions that affect personal data processing, privileged access, or production integrity should be treated as particularly sensitive and reviewed with greater scrutiny.

9. Review and Maintenance

This policy shall be reviewed at least annually and whenever there is a significant change to the organization’s technology stack, operating model, regulatory obligations, or security risk profile. Examples include adoption of new cloud services, major application refactoring, changes to customer data handling, or a significant security incident. The review should confirm that the requirements remain practical for a small legal technology business while still providing meaningful control over development and release risk.

The Information Security Owner is responsible for coordinating the review, collecting feedback from Engineering, Operations, and Privacy stakeholders, and proposing updates. The Managing Director shall approve material revisions. If review findings indicate that controls are not being followed, management must require corrective action, assign owners, and set deadlines for closure. Any policy update should be communicated to relevant personnel and, where needed, reflected in training, onboarding, vendor requirements, or operating procedures.

Records of policy reviews, approvals, and resulting changes must be retained to demonstrate governance and continual improvement. If repeated issues are identified, the organization should update tooling, training, or process design rather than relying solely on reminders. This is especially important in a small team, where informal habits can quickly replace intended controls if maintenance is not deliberate.

10. Related Standards

ISO 27001 is relevant to this policy because it establishes expectations for information security governance, secure development, change control, access management, logging, vulnerability management, and continual improvement. This policy provides practical controls that support those expectations by requiring documented approvals, traceability, testing, and evidence for software and infrastructure changes. It helps Ligala Tech demonstrate that security is managed systematically rather than ad hoc.

The Singapore PDPA is connected to this policy because many application and infrastructure changes can affect the collection, use, disclosure, protection, retention, and transfer of personal data. By requiring review of changes that impact data access, logging, retention, encryption, and authentication, the policy reduces the risk of unlawful or accidental exposure of personal data. For a legal technology company, this is especially important because client files and user information may include sensitive or confidential material.

This policy also supports related security practices such as access control, incident response, vulnerability management, asset management, and business continuity. Secure development and change management are foundational controls that reduce downstream incidents and support legal, contractual, and customer trust obligations. When implemented consistently, they improve the reliability of services that Ligala Tech provides to legal professionals and help preserve the confidentiality and integrity expected in the legal sector.