Cloud Platform Policy

Purpose of the Policy

This policy establishes the mandatory security, governance, operational, and compliance requirements that govern the design, deployment, configuration, and use of cloud infrastructure and cloud-based services across Legistify. It is intended to protect the confidentiality, integrity, and availability of Legistify's information assets, customer data, and cloud-hosted systems — including Codex, LMT, NMT, and any other applications operating on or integrating with cloud infrastructure.

This policy provides a consistent, auditable framework for cloud governance that supports internal security assurance and external assessments, including ISO/IEC 27001, SOC 2, and the Digital Personal Data Protection Act, 2023 (DPDP Act). It defines clear accountability across Information Security, DevOps/Cloud Engineering, Development, Administration, and Management functions, and ensures that cloud resources are provisioned, configured, monitored, and decommissioned in line with recognised industry standards and best practices.

Procedures

Cloud Governance

Legistify maintains a list of approved cloud service providers and services, reviewed by Information Security and Cloud Engineering. Personnel must not provision infrastructure or subscribe to cloud services outside the Approved Services List without prior review and approval. New cloud services are evaluated for security posture, compliance certifications, data residency, and shared responsibility implications before approval.

Cloud accounts are created and owned centrally by the Cloud Engineering/DevOps function, with each account assigned a designated business and technical owner. Use of personal or non-corporate email addresses to create or administer Legistify cloud accounts is prohibited.

Legistify maintains logical and, where applicable, network-level separation between Production, UAT, and Development environments. Production data must not be copied into non-production environments unless masked, anonymised, or covered by an approved exception. All cloud resources must be tagged at creation with environment, owner/team, application/product, cost centre, and data classification.

All changes to Production cloud infrastructure must follow a documented change management process covering request, risk assessment, peer review, approval, and post-implementation verification. Emergency changes are permitted only under a defined emergency procedure, with retrospective review within 24–48 hours.

Identity and Access Management

Access to cloud resources is granted strictly on a least-privilege, need-to-know basis. Access is assigned through defined roles mapped to job function rather than direct, ad-hoc grants. MFA is mandatory for all human access to cloud management consoles, VPN/bastion access, and any system providing administrative access to cloud infrastructure — without exception for root and privileged accounts.

Human user identities and machine/service identities are provisioned and managed separately. Service identities are scoped to the minimum permissions required and must not be used interactively. Long-lived static credentials for service identities should be avoided in favour of short-lived, automatically rotated credentials wherever supported.

Access to cloud accounts, environments, and privileged roles is reviewed at least quarterly. Access for terminated employees or contractors must be revoked within 24 hours of their last working day.

The cloud provider root account must not be used for day-to-day operations. It must be protected with MFA, credentials stored securely, and each use must generate an alert to Information Security for review.

Network Security

Cloud workloads are deployed within logically segmented virtual networks, with subnets separated by function and by environment. Resources that do not require direct internet access — such as databases and internal services — must be deployed in private subnets. Only resources with an explicit business requirement for public accessibility may be placed in public subnets.

Security group and firewall rules follow the principle of least privilege — default-deny inbound, with explicit allow rules scoped to specific ports, protocols, and source ranges. Broad allow rules on administrative ports such as SSH/RDP are prohibited. Direct administrative access to cloud compute resources from the public internet is prohibited and must be routed through a bastion host, VPN, or equivalent secure access broker with MFA and logging enabled.

All external-facing services must enforce HTTPS/TLS 1.2 or higher. TLS certificates must be issued by trusted certificate authorities, monitored for expiry, and renewed before expiration. Internet-facing applications should be protected by a Web Application Firewall configured with rules addressing the OWASP Top 10.

Data Protection

All data processed or stored within Legistify's cloud environment must be classified in accordance with the Data Classification Policy. All storage services holding Confidential or Restricted data must have encryption at rest enabled. Data classified as Confidential or Restricted must be encrypted in transit using TLS 1.2 or higher.

Cryptographic keys are managed through a managed key management service, with defined key owners, access policies, and rotation schedules. Access to key management operations must be restricted to authorised personnel and logged. Secrets must be stored in a dedicated secrets management solution and must never be hardcoded in source code, configuration files, container images, or CI/CD pipeline definitions.

Personal data processed in Legistify's cloud environment must comply with the DPDP Act, 2023, and any other applicable jurisdiction-specific requirements. Data must be retained only as long as required and deleted securely at the end of its retention period.

Container and Serverless Security

Container images must be built from minimal, hardened base images and scanned for known vulnerabilities prior to deployment. Containers must run as non-root users and with read-only file systems where technically feasible. Secrets must be injected at runtime from a secrets manager and must never be baked into container images.

Serverless functions must follow the same least-privilege IAM principles as other workloads, with execution roles scoped to only the permissions required by the specific function.

Application and API Security

Applications deployed on cloud infrastructure must be developed in accordance with Legistify's Secure Development Policy and relevant OWASP guidance. All public APIs must be protected by authentication and authorisation controls. API gateways should be used for internet-facing APIs to provide authentication, rate limiting, and logging. Input validation must be enforced on all API endpoints, and sensitive data must not be included in API responses beyond what is required.

Monitoring, Logging, and Alerting

Logging must be enabled across all Production cloud accounts for management and control plane activity, data access on critical resources, network flow logs, application logs, and security service findings. Log retention periods are defined per log category based on operational, security, and regulatory requirements. Logs must be protected against unauthorised modification or deletion, and access to raw logs is restricted to authorised Information Security and Cloud Engineering personnel.

Alerting thresholds and escalation paths are defined for critical events — including root account use, security groups opened to the internet, disabled logging, and repeated authentication failures — with alerts routed to the responsible on-call or Information Security function in near real time.

Backup and Disaster Recovery

All Production systems and data classified as Confidential or Restricted must be backed up in accordance with a documented backup schedule.

Restoration procedures must be tested periodically to validate that backups are recoverable and that recovery time objectives can be met. Legistify maintains a Disaster Recovery Plan covering critical systems, defining failover procedures, roles and responsibilities, and communication protocols, tested at least annually.

Vulnerability and Patch Management

Cloud infrastructure, container images, and applications are scanned for vulnerabilities on a recurring, automated basis. Operating systems, middleware, and application dependencies must be kept current with vendor-released security patches.

Incident Response

A cloud security incident is any event that compromises, or threatens to compromise, the confidentiality, integrity, or availability of Legistify's cloud infrastructure, applications, or data. Any Personnel identifying a suspected incident must report it immediately to Information Security through the designated incident reporting channel.

Critical incidents require an initial response within 1 hour and executive notification within 4 hours.

Compliance and Regulatory Requirements

This policy and its supporting controls are designed to support Legistify's ISMS and alignment with ISO/IEC 27001, SOC 2 Trust Services Criteria, and the DPDP Act, 2023. Cloud processing of personal data must comply with applicable data protection and privacy laws.

Cloud security is a shared responsibility between Legistify and its cloud service provider(s). The precise division of responsibility varies by service model (IaaS, PaaS, SaaS), and Legistify is responsible for configuring, monitoring, and maintaining security within its own accounts and applications, regardless of provider-managed infrastructure controls.

Third-Party and Managed Cloud Services

Prior to onboarding any third-party or managed cloud service that will process, store, or transmit Legistify or customer data, a security and privacy assessment must be performed. AI/ML managed services undergo additional review of data usage, model training practices, data residency, and PII controls prior to adoption. Access granted to third-party providers must be scoped to the minimum necessary, time-bound where appropriate, and reviewed on the same cadence as internal access reviews.

Cloud Cost and Resource Management

All cloud resources must be tagged per the tagging standard to support cost allocation and ownership tracking. Idle or unused resources are identified on a recurring monthly basis and decommissioned or justified. Cloud spend is monitored against budget with anomaly detection for unexpected cost spikes. Automated budget alerts are configured to notify designated owners when spend approaches or exceeds defined thresholds.

Roles & Responsibilities

Policy Revision History