Skip to main content

Ligala Tech Pte Information Security Risk Management Policy

Ligala Support

Table of Contents

1. Purpose

Ligala Tech Pte Information Security Risk Management Policy establishes a consistent, repeatable, and risk-based method for identifying, assessing, prioritizing, treating, accepting, tracking, and reviewing information security risks across the company’s cloud services, applications, infrastructure, third-party services, and business operations.

Ligala Tech Pte is a Singapore-based legal technology provider serving organizations that handle sensitive client, matter, and operational data. Security failures in this environment can affect confidentiality, integrity, and availability, and can also create legal, contractual, privacy, and reputational consequences for both clients and the company. This policy exists to ensure that security risks are managed deliberately rather than informally, and that the company can demonstrate sound governance and due diligence.

The policy provides a practical framework for handling risks discovered through vulnerability assessments, cloud security reviews, audit findings, incident investigations, customer due diligence, change management, and day-to-day operations. It is designed to ensure that each risk has clear ownership, an explicit treatment decision, and a recorded follow-up path, especially where sensitive legal client data or privileged access is involved.

This policy supports the organization’s information security management objectives and aligns with ISO 27001 principles by promoting consistent risk assessment, documented treatment decisions, management oversight, and continual improvement appropriate to a small organization with limited staff but high data sensitivity.

2. Scope

This policy applies to all Ligala Tech Pte employees, directors, contractors, temporary staff, and third-party service providers who create, access, manage, administer, or support information assets on behalf of the company. It applies regardless of whether access is direct, remote, temporary, privileged, or automated.

The policy covers all environments and systems used by the company, including production, development, testing, staging, cloud accounts, endpoint devices, identity platforms, SaaS tools, collaboration tools, source code repositories, backup systems, and outsourced services that process, store, or transmit company or client information. It also includes risks introduced by integrations, APIs, and administrative access granted to vendors or service partners.

The scope includes risks affecting customer data, legal case-related content, credentials, access controls, application logic, infrastructure configuration, logging, monitoring, business continuity, privacy obligations, and supplier dependencies. Risks identified through internal reviews, security testing, penetration tests, cloud security tooling, access reviews, incidents, audits, and customer questionnaires are all within scope.

Because Ligala Tech Pte is a small organization, responsibilities may be shared across a limited number of people. However, shared execution does not remove accountability. Any issue that could affect legal client data, service continuity, regulatory obligations, or trust in the company’s services is in scope and must be managed under this policy.

3. Policy Statement

Ligala Tech Pte shall maintain a formal information security risk management process that is documented, repeatable, and proportionate to the organization’s size and operating environment. All identified information security risks shall be assessed using defined criteria for likelihood and impact, prioritized according to business and client context, assigned to a responsible owner, and tracked through closure or approved acceptance.

Risks affecting legal client data, privileged access, authentication systems, internet-exposed services, secrets, or cloud administrative functions shall receive heightened attention. These risks can create direct pathways to unauthorized access or data compromise and may have disproportionate legal and reputational consequences. For that reason, they must be escalated promptly and may not remain unresolved without documented compensating controls or an approved exception.

Risk management shall be used to support operational decisions, not merely to create records. A risk that is accepted, transferred, deferred, or mitigated must have a documented rationale, an accountable approver, a review date, and evidence of the decision. High and critical risks shall not be left open indefinitely, and exceptions shall be treated as controlled exceptions rather than routine practice.

The company shall maintain a balanced approach: controls and review activities should be light enough for a 1–10 person organization to operate consistently, but rigorous enough to demonstrate due care. Where immediate remediation is not possible, Ligala Tech Pte shall implement compensating controls, monitoring, and time-bound action plans to reduce exposure until the issue is fully addressed.

4. Roles and Responsibilities

  • Managing Director / Executive Sponsor: Approves the overall risk management approach, authorizes acceptance of high and critical risks, reviews recurring unresolved issues, decides on risk exceptions that exceed normal authority, and ensures adequate resources are available for remediation and monitoring.
  • Information Security Lead / Security Owner: Owns this policy, defines and maintains the risk methodology, validates severity ratings, coordinates risk reviews, reports trends and overdue items, ensures risks are recorded and tracked, and advises on treatment decisions and exception handling.
  • Engineering Lead / Product Engineering Owner: Owns security remediation for applications, code, cloud infrastructure, infrastructure-as-code, and deployment pipelines; assigns engineering tasks; verifies implementation of fixes; and ensures findings from testing or engineering reviews are resolved or formally accepted.
  • Operations / IT Administrator: Owns identity, endpoint, SaaS, cloud administration, backup, and access control risks; remediates IAM and configuration issues; performs and retains access review evidence; and implements compensating controls where immediate remediation is not possible.
  • Data Protection / Privacy Responsible Officer: Reviews risks involving personal data, legal matter data, and privacy obligations; advises on PDPA and contractual implications; and confirms that treatment plans address confidentiality, lawful processing, retention, and disclosure concerns.
  • Risk Register Owner / PMO Function if assigned: Maintains the central risk register, records each risk’s description, owner, status, severity, treatment decision, due date, evidence links, and review history; and escalates overdue or unassigned items according to this policy.
  • All Staff and Contractors: Promptly report suspected weaknesses, incidents, or control failures; follow approved control requirements; complete assigned remediation tasks by the agreed due date; and do not independently accept, defer, or transfer security risk outside their authority.

5. Policy Requirements

  • A documented information security risk assessment methodology shall be maintained. Owner: Information Security Lead. Frequency: reviewed annually and after major business, technology, or threat changes. Evidence: approved methodology document, scoring criteria, and version history.
  • All identified information security risks shall be entered into the central risk register within five business days of discovery. Owner: Risk Register Owner or Information Security Lead. Frequency: each risk. Evidence: dated register entry showing source, description, affected asset or system, and initial severity.
  • Every risk shall have a named business or technical owner accountable for treatment. Owner: Risk Register Owner. Frequency: at registration and each review cycle. Evidence: register field showing assigned owner and acknowledgment or assignment record.
  • Each risk shall be assessed for likelihood, impact, and overall severity using a defined scoring model that considers confidentiality, integrity, availability, legal exposure, and client trust. Owner: Information Security Lead with input from Engineering and Data Protection. Frequency: each risk and upon material change. Evidence: completed assessment worksheet or scoring record.
  • High and critical risks affecting client data, authentication, privileged access, public exposure, or production cloud services shall have a remediation plan within five business days. Owner: Risk owner. Frequency: per finding. Evidence: remediation ticket, target date, and agreed plan.
  • High and critical risks shall not remain open beyond 30 calendar days without executive-approved exception or documented compensating controls. Owner: Executive Sponsor and risk owner. Frequency: weekly review until closure. Evidence: approval record, compensating controls, and updated register status.
  • Medium risks shall have treatment plans and target dates within 20 business days of assessment. Owner: Risk owner. Frequency: per finding. Evidence: treatment ticket and planned closure date.
  • Low risks may be accepted only by the assigned risk owner and must still be recorded with a review date. Owner: Risk owner. Frequency: per finding and annual review. Evidence: acceptance note and review date in the register.
  • Remediation actions shall include implementation, testing, and verification before closure. Owner: Engineering Lead or Operations / IT Administrator, depending on the control area. Frequency: per fix. Evidence: change record, test result, and closure approval.
  • Compensating controls shall be documented whenever full remediation is delayed. Owner: Risk owner with Security Lead review. Frequency: whenever delay occurs, with weekly review for high and critical risks. Evidence: control narrative, monitoring steps, and logs or screenshots where applicable.
  • Risk acceptance, transfer, or avoidance decisions shall be approved at the appropriate authority level and may not be made informally through chat or email alone. Owner: Executive Sponsor for high and critical risks; risk owner for low risks; Security Lead for documentation. Frequency: per decision. Evidence: signed or ticketed approval, decision record, and updated risk register.
  • All open risks shall be reviewed at least monthly, and open high and critical risks shall be reviewed weekly until closed. Owner: Information Security Lead. Frequency: monthly overall, weekly for high and critical. Evidence: review notes, dashboard, and updated action log.
  • Post-incident and post-audit findings shall be evaluated for risk implications within five business days. Owner: Information Security Lead and relevant operational owner. Frequency: each incident or audit finding. Evidence: incident review note or audit disposition record linked to the risk register.
  • Third-party and SaaS risks shall be assessed before onboarding and reviewed annually or upon major service change. Owner: Operations / IT Administrator and Security Lead. Frequency: onboarding and annual review. Evidence: vendor assessment, questionnaire, approval record, and mitigation plan where needed.

6. Implementation Guidance

Ligala Tech Pte should operate this policy through a lightweight but disciplined workflow that fits a small organization. The recommended foundation is a central risk register maintained in a shared security tracker, ticketing system, or GRC tool. Each entry should include the issue description, affected system, business impact, severity, owner, treatment choice, due date, evidence links, and current status. Linking the risk record to engineering tickets, access review outputs, cloud alerts, and incident reports helps ensure that risks can be traced from discovery to closure.

Assessment should use a simple scoring model that combines likelihood and impact, with additional weight for client data exposure, privileged access, public exposure, and regulatory consequences. For example, an IAM misconfiguration in a production cloud account should automatically trigger review by the Operations / IT Administrator and the Security Lead because permission errors can expose sensitive matter data or enable account compromise. If a vendor tool reports a severity that does not reflect the business reality, the Security Lead should adjust the rating and document the rationale.

The remediation workflow should be explicit and consistent. Upon discovery, the risk owner is assigned, the target date is set according to severity, and a treatment path is selected. Engineering or operations tasks should include the risk identifier so that progress can be monitored. Weekly reviews should focus on high and critical items, overdue tasks, blockers, and any decision requiring executive input. Lower-risk items may be reviewed asynchronously if the status and evidence are recorded in the register.

Practical tooling may include cloud security posture management alerts, identity access review exports, vulnerability scanners, endpoint management tools, ticketing systems, and a shared dashboard for leadership reporting. Compensating controls should be specific and measurable, such as disabling public exposure, enforcing MFA, rotating secrets, limiting privileged access, restricting firewall rules, or increasing monitoring on affected accounts. Staff should be aware that security findings are business obligations because the company handles legal client data and depends on customer trust.

7. Monitoring, Evidence, and Compliance

Monitoring shall be continuous and proportionate to risk. The Information Security Lead shall maintain a dashboard showing open risks by severity, age, owner, due date, and treatment status. Weekly monitoring is required for open high and critical risks, while the full register shall be reviewed monthly to identify overdue items, repeated control failures, and patterns indicating systemic weaknesses. Where a risk is linked to active exploitation, internet exposure, or access to client data, the Security Lead may require daily status updates until exposure is removed.

Evidence of compliance shall be retained in a form that supports internal review and external assurance. Acceptable evidence includes the risk register, scoring worksheets, approval records, remediation tickets, change requests, test results, screenshots of control changes, access review logs, vendor review files, incident postmortems, and management meeting minutes. Evidence must show what was found, who owned it, what decision was made, when action was due, and how closure was verified.

Escalation triggers shall include any high or critical risk overdue by more than five business days, any risk affecting legal client data without an approved treatment plan, any risk accepted without proper authority, any exception that has expired, and any repeated control failure in the same system or team. These triggers shall be escalated to the Managing Director or Executive Sponsor with a concise summary of exposure, impact, and recommended action. Compliance metrics shall be reported at least quarterly to leadership and should include open risks by severity, percentage overdue, average time to close, number of exceptions, and number of recurring findings.

8. Exceptions

Exceptions to this policy may be granted only when a control cannot be implemented immediately and the business rationale is documented. An exception request shall describe the risk, the reason remediation is delayed, the compensating controls, the expiry date, and the person requesting and approving the exception. High and critical risks require approval by the Managing Director or Executive Sponsor in addition to review by the Security Lead. Low risks may be approved by the assigned risk owner with Security Lead documentation.

All exceptions shall be recorded in the risk register and linked to supporting evidence. Exceptions may not be indefinite. Each exception must have a defined expiry date, normally not exceeding 90 days for high and critical issues unless renewed by executive approval with documented business justification. On expiry, the risk must be remediated, re-approved with updated rationale, or escalated for leadership decision. The Security Lead shall review all open exceptions monthly to confirm that they remain justified and that compensating controls continue to operate effectively.

9. Review and Maintenance

This policy shall be reviewed at least annually by the Information Security Lead and approved by the Executive Sponsor. It shall also be reviewed after a major security incident, a material architecture change, a significant business change, or evidence that the current risk process is not effectively driving remediation. Review outcomes should confirm whether risk thresholds, treatment timelines, approval levels, and escalation paths remain suitable for Ligala Tech Pte’s size and threat environment.

Any revision shall be version controlled, communicated to affected staff, and reflected in related procedures, templates, and training materials. The review record shall state what changed, why it changed, who approved it, and the effective date. Where changes affect live workflows, the Security Lead shall provide transition guidance so that open risks, exceptions, and remediation tickets are not left in ambiguous states.

ISO 27001 is the primary standard supporting this policy because it requires a formal information security management system, risk-based decision-making, documented treatment of risks, and management oversight. This policy converts those requirements into internal operating rules so Ligala Tech Pte can identify, assess, respond to, and evidence security risk decisions in a repeatable way.

Singapore PDPA is also directly relevant because many risks managed under this policy involve personal data or legal client data. The policy supports PDPA obligations by requiring careful assessment of confidentiality, lawful processing, access control, vendor management, and breach-related risks. When a risk may affect personal data handling, the Data Protection / Privacy Responsible Officer must be involved in evaluating legal and contractual consequences.

This policy also connects to related security practices such as access control, vulnerability management, incident management, supplier security, business continuity, and change management. Findings from those processes must be captured as risks when they have a meaningful security impact, and they must be tracked through treatment or accepted exception. In this way, the policy acts as the governance bridge between day-to-day security operations and the broader ISO 27001-aligned control environment, helping Ligala Tech Pte demonstrate accountability, diligence, and continual improvement.

Related articles

Comments

0 comments

Please sign in to leave a comment.