Skip to main content

Ligala Tech Pte Access Control and Identity Management Policy

Ligala Support

Table of Contents

1. Purpose

This policy establishes the rules and operating expectations for controlling access to Ligala Tech Pte’s systems, client matter records, administrative tools, cloud services, and supporting information assets. It is designed to ensure that only authorized individuals can access data and functions appropriate to their role, and that access is granted, reviewed, modified, and removed in a controlled and auditable manner.

Ligala Tech Pte operates in legal technology, where even a small team may handle sensitive client matter information, personal data, credentials, and administrative functions that affect customer trust and business continuity. Because the company is based in Singapore and processes personal data, it must maintain reasonable security arrangements to prevent unauthorized access, disclosure, loss, or misuse. This policy supports that duty by defining minimum access control and identity management practices that reduce the likelihood of account compromise, accidental exposure, and privilege misuse.

This policy also supports the organization’s information security governance by aligning access control decisions with formal approval, least privilege, unique user identity, and periodic review. For a small firm, the policy must be practical and enforceable without excessive administrative burden. Accordingly, it emphasizes simple but rigorous controls that can be operated consistently by a lean team while still meeting ISO 27001 expectations for access control governance.

2. Scope

This policy applies to all Ligala Tech Pte personnel, including employees, directors, interns, contractors, consultants, temporary staff, and any third parties who are granted access to company systems or information. It applies regardless of whether access is local, remote, on-site, or cloud-based. It also applies to all identity stores, authentication mechanisms, and privileged accounts used to administer business systems.

The policy covers access to all production, test, and administrative environments, including email, collaboration tools, source code repositories, cloud consoles, customer support systems, CRM tools, identity platforms, endpoint devices, and any platform that stores or processes client matter records or personal data. Where a vendor provides a hosted service, the organization must still ensure access control expectations are applied through configuration, contract, and administrative practice.

This policy applies to all stages of the employment or engagement lifecycle, including onboarding, role changes, temporary assignments, leave, suspension, and termination. It also applies to service accounts, shared technical integrations, API keys, privileged administrative access, and emergency access mechanisms. If any system cannot support a requirement in this policy, the system owner must document the limitation and obtain an approved exception before use.

3. Policy Statement

Ligala Tech Pte shall implement and maintain access controls so that access is granted only to authorized users, only for approved business purposes, and only to the minimum level necessary to perform assigned duties. Access shall be based on unique user identities wherever technically feasible, and generic or shared accounts shall be avoided except where explicitly approved for a documented operational need and compensating controls are in place.

Access rights shall be approved before provisioned, reviewed periodically, and removed promptly when no longer required. Privileged access shall be tightly limited, separately controlled, and subject to heightened review because it can materially affect the confidentiality, integrity, and availability of systems and client data. Passwords, multi-factor authentication, session controls, and other authentication safeguards shall be implemented in a manner appropriate to the sensitivity of the data and the risk of the system.

Identity and access management decisions shall support legal and contractual duties, protect client matter records, and reduce the likelihood of unauthorized disclosure of personal data. Managers and system owners are accountable for ensuring that access matches role requirements, while users are responsible for protecting their credentials and reporting suspicious activity promptly. Any deviation from this policy must be formally approved, documented, time-limited, and periodically revalidated.

4. Roles and Responsibilities

  • Managing Director: Provides executive sponsorship, approves high-risk exceptions, and ensures access control priorities are resourced and enforced across the organization.
  • Operations Lead or Office Manager: Coordinates onboarding and offboarding requests, tracks access approvals, maintains the access inventory, and ensures that joiner-mover-leaver actions are completed on time.
  • System Owner: Defines access roles for the system under their control, approves or rejects access requests, reviews user entitlements periodically, and confirms that accounts reflect business need.
  • Information Security Lead or designated security officer: Maintains this policy, advises on control design, reviews privileged access and exceptions, and reports access control risks or noncompliance to management.
  • Human Resources or Engagement Administrator: Notifies Operations and relevant managers of joins, role changes, leaves, and terminations, and confirms effective dates for access changes.
  • Line Manager: Verifies the need for access, approves role-based entitlements for direct reports, and confirms when access should be reduced, transferred, or removed.
  • All Users: Protect their credentials, use only their own accounts, follow authentication requirements, avoid sharing accounts or passwords, and report suspected compromise, unauthorized access, or accidental disclosure immediately.
  • IT Administrator or Managed Service Provider: Implements technical access controls, provisions and deprovisions accounts only on approved instruction, maintains logs, and supports access reviews and incident investigations.

5. Policy Requirements

  • Every user must have a unique, named account for business system access; shared accounts are prohibited unless the System Owner approves a documented operational exception. Owner: IT Administrator and System Owner. Frequency: at account creation and whenever new access is provisioned. Evidence: user account list, provisioning ticket, exception record if applicable.
  • Access must be approved before provisioning by the user’s Line Manager and the relevant System Owner, with sensitive or privileged access also requiring Information Security Lead review. Owner: Operations Lead. Frequency: each access request. Evidence: approved access request, email or workflow record, authorization log.
  • Access shall follow least privilege, meaning users receive only the minimum permissions required for their current role and assigned tasks. Owner: System Owner. Frequency: upon provisioning, role changes, and quarterly review. Evidence: role-to-access matrix, entitlement review records, access change tickets.
  • Multi-factor authentication must be enabled for all remote access, administrative access, cloud services, and any system containing client matter records or personal data where supported. Owner: IT Administrator. Frequency: continuous enforcement, with verification monthly. Evidence: MFA configuration screenshots or export, access policy settings, authentication logs.
  • Privileged accounts must be separate from standard user accounts and used only for administrative tasks; day-to-day work must be performed with non-privileged accounts. Owner: IT Administrator and all privileged users. Frequency: continuous, with monthly usage review. Evidence: privileged account inventory, admin activity logs, endpoint or cloud audit logs.
  • Privileged access must be reviewed by the System Owner and Information Security Lead at least quarterly, including confirmation that each privileged user still requires access. Owner: System Owner. Frequency: quarterly. Evidence: privileged access review report, approval or removal actions, meeting notes or signed review record.
  • User access reviews for standard accounts must be performed at least semi-annually, and any discrepancy must be corrected promptly. Owner: System Owner. Frequency: every six months. Evidence: access review worksheet, attestation from manager, remediation tickets.
  • Joiner-mover-leaver changes must be processed within one business day of notification for leavers and within two business days for movers, unless a shorter deadline is required for risk reasons. Owner: Operations Lead. Frequency: each employment or engagement change. Evidence: HR notification, deprovisioning or modification ticket, timestamped completion record.
  • Access for terminated users must be disabled immediately upon termination notice or at the end of the approved engagement, whichever occurs first, and credentials, tokens, and device sessions must be revoked. Owner: IT Administrator. Frequency: each termination event. Evidence: offboarding checklist, disablement logs, token revocation records.
  • Service accounts, API keys, and integration credentials must be uniquely identified, owned by a System Owner, restricted to the minimum necessary permissions, and stored securely. Owner: System Owner and IT Administrator. Frequency: upon creation, quarterly review, and upon change. Evidence: service account register, secret management records, rotation log.
  • Passwords and authentication secrets must not be shared, written in plain text, or transmitted insecurely. Where passwords are used, they must meet organization-defined complexity and reuse controls, and defaults must be changed before production use. Owner: All Users and IT Administrator. Frequency: continuous, with validation during setup and periodic audit. Evidence: password policy settings, onboarding checklist, audit findings.
  • Temporary access, emergency access, and break-glass privileges must be time-bound, logged, and reviewed after each use. Owner: Information Security Lead and System Owner. Frequency: per event, with review within one business day after use. Evidence: emergency access log, incident or ticket record, post-use review note.
  • Account creation, modification, suspension, and deletion must be executed only through approved request channels and recorded in a centralized access log or ticketing system. Owner: Operations Lead. Frequency: each lifecycle event. Evidence: access management tickets, centralized access log, audit trail.

6. Implementation Guidance

Ligala Tech Pte should implement this policy using a lightweight but disciplined joiner-mover-leaver process. A single access request workflow can be used across email, cloud tools, code repositories, and internal systems, provided it records the requester, approvers, requested role, effective date, and completion status. For a small organization, a ticketing system or shared workflow form is sufficient if it produces durable records and supports audit retrieval.

The company should maintain a simple role-to-access matrix for common job functions such as operations, engineering, client support, and management. This matrix should define standard entitlements for each role and identify any elevated permissions that require separate approval. Using role-based access templates reduces ad hoc provisioning and helps ensure that new hires receive consistent access while limiting the risk of over-provisioning. Where a system cannot support role templates, the owner should define an equivalent manual approval process.

Privileged access should be kept intentionally small. Administrative functions should be assigned only to named individuals who require them, and those accounts should be protected with MFA and stronger monitoring. If the organization uses a managed service provider, the contract should require named accounts, logging, rapid deprovisioning, and notification of personnel changes. Shared vendor credentials should be phased out or isolated behind a secret management platform with strict audit trails.

Operationally, offboarding should be treated as time-critical. HR or the engagement administrator should notify Operations immediately when a departure is confirmed. The standard offboarding checklist should include email, cloud applications, remote access, endpoint device return, revocation of API keys, and removal from collaboration groups. For movers, access should be adjusted before or on the effective date so the user does not retain permissions from the prior role that are no longer justified.

Technical tooling may be simple but should be consistent. A cloud identity provider with MFA, centralized groups, and logging can support most needs for a small firm. Secret storage should be used for service credentials instead of embedding them in documents or code. Logs from authentication, admin changes, and access reviews should be retained so that unusual access patterns can be investigated. Where possible, periodic review can be supported by exported reports from the identity platform and system dashboards rather than manual checks alone.

7. Monitoring, Evidence, and Compliance

Compliance with this policy shall be monitored through recurring access reviews, provisioning audits, and exception tracking. The Information Security Lead or designated reviewer should sample access requests and completed changes each quarter to confirm that approvals are present, deadlines were met, and entitlements match business need. Any account that appears dormant, excessively privileged, or unowned must be investigated and either justified or removed.

Required evidence includes access request records, approval traces, user account inventories, role matrices, privileged account listings, offboarding checklists, MFA configuration records, authentication logs, and exception approvals. These records should be retained in a centralized repository accessible to management and auditors. For a small firm, a shared compliance folder or governed document repository is acceptable if access is restricted and retention is controlled. Records should be sufficient to show who approved access, when it was granted, and when it was removed or reviewed.

Key metrics should include the number of open privileged accounts, percentage of users covered by MFA, time to disable terminated accounts, number of overdue access reviews, and number of unresolved exceptions. Escalation is required if a terminated account remains active beyond the required deadline, if privileged access is found without approval, if a shared account is discovered without exception, or if a significant access review discrepancy is not remediated promptly. Repeated failures should be reported to the Managing Director and may require corrective action, retraining, or vendor review.

8. Exceptions

Exceptions to this policy are allowed only when a business or technical need prevents immediate compliance and when compensating controls reduce the risk to an acceptable level. The request must describe the control gap, affected systems, duration, compensating measures, and the risk of noncompliance. Exceptions must be approved by the System Owner and Information Security Lead, with high-risk exceptions also approved by the Managing Director.

Every exception must be documented in an exception register and include a clear expiry date. Temporary exceptions should be limited to the shortest practical period, generally not exceeding 90 days unless specifically justified. Before expiry, the owner must either close the gap, renew the exception with updated justification, or remove the affected access or process. Expired exceptions without renewal are not valid and must be treated as noncompliance.

Exception reviews should occur at least monthly for active exceptions. The review should confirm that the rationale still exists, compensating controls are functioning, and remediation progress is on track. Any exception that creates material exposure to client matter records or personal data must be escalated immediately, and management may require compensating controls such as enhanced logging, restricted network access, or additional approval steps.

9. Review and Maintenance

This policy shall be reviewed at least annually by the Information Security Lead, with input from Operations, System Owners, and management. A review should also occur after significant changes such as a security incident, major technology change, organizational restructuring, or a new legal or regulatory requirement affecting access control. The review should confirm that the policy remains practical for a small firm while still addressing current risks.

Maintenance of the policy should include updates to reflect changes in identity platforms, new business systems, changes in vendor relationships, and lessons learned from access audits or incidents. Related procedures, such as the onboarding checklist, offboarding checklist, privileged access review template, and access request form, should be updated in parallel so that the policy remains operationally usable. The document owner should ensure version control, approval history, and distribution to relevant stakeholders.

Each annual review should confirm that review frequencies, approval requirements, and evidence expectations remain appropriate for Ligala Tech Pte’s size and risk profile. If the company grows, handles more sensitive data, or adopts additional cloud services, the policy may need stronger controls or more frequent review. Any substantive revision should be approved by management and communicated to all users before taking effect.

ISO 27001 is the primary management system standard that supports this policy by requiring formal access control governance, risk-based control selection, accountability, and evidence of operation. This policy translates those expectations into practical rules for user provisioning, privileged access, review cycles, and exception handling. In particular, it supports the ISO 27001 emphasis on control over user access management, authentication, and periodic review of privileges.

Singapore’s Personal Data Protection Act, including its obligation to make reasonable security arrangements, is directly supported by this policy because it reduces the risk of unauthorized access, disclosure, and misuse of personal data. Ligala Tech Pte may handle client and employee information in systems that require strict access restriction, and this policy defines the organizational and technical measures needed to protect that data. The policy also supports accountability by ensuring access is authorized, traceable, and removable when no longer needed.

This policy should be read together with any supporting procedures for account provisioning, incident response, acceptable use, password management, remote access, and data classification. Where a conflict exists, the stricter requirement shall apply unless legal counsel or management authorizes a documented exception.

Comments

0 comments

Please sign in to leave a comment.