Cloud Platform Policy

Purpose of the Policy

This Cloud Platform 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. The Policy is intended to:

This Policy sets the mandatory baseline. Detailed, tool-specific procedures (e.g., runbooks, configuration standards) shall be maintained as supporting documents and are subordinate to this Policy.

Scope

This Policy applies, without exception, to:

Procedures

Cloud Governance

Legistify shall maintain a list of approved cloud service providers and approved services within each provider, maintained and 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 shall be evaluated for security posture, compliance certifications, data residency, and shared responsibility implications prior to approval.

Cloud accounts and subscriptions shall be created and owned centrally by the Cloud Engineering/DevOps function, under the oversight of Information Security. Each cloud account shall have a designated business and technical owner, recorded in the organisation's asset inventory. Use of personal or non-corporate email addresses to create or administer Legistify cloud accounts is prohibited. Billing and organisational-level access shall be restricted to a minimal number of authorised individuals.

Legistify shall maintain logical and, where applicable, network-level separation between Production, UAT, and Development environments. Production data shall not be copied into non-production environments unless masked, anonymised, or sanitised, or an explicit, documented, time-bound exception has been approved.

Access to Production environments shall be more restrictive than access to non-production environments and subject to additional approval and monitoring controls. Separate IAM roles, credentials, and where applicable separate cloud accounts or VPCs shall be used per environment to prevent cross-environment impact.

All cloud resources shall be tagged at creation with, at minimum: environment, owner/team, application/product, cost centre, and data classification. Untagged or improperly tagged resources shall be identified through periodic review and remediated or decommissioned. Resource ownership shall be traceable at all times to a responsible individual or team.

All changes to Production cloud infrastructure shall follow a documented change management process, including request, risk assessment, peer/technical review, approval, and post-implementation verification. Emergency changes shall be permitted only under a defined emergency change procedure, with retrospective review and approval within 24–48 hours. Infrastructure changes should be implemented through a controlled, version-tracked deployment process wherever technically feasible, to ensure changes are reviewable and reversible.

Cloud architecture shall follow the principles of least privilege, defence in depth, segmentation, and secure-by-default configuration. Reference architectures should be developed and maintained for common workload patterns. New architectures or significant architectural changes affecting Production shall undergo a security architecture review prior to deployment.

Requests to adopt a new cloud service, managed service, or SaaS integration shall be submitted to Information Security and Cloud Engineering for evaluation. Evaluation shall consider data sensitivity and classification, compliance certifications of the vendor/service, encryption and access control capabilities, integration/API security, and cost. Approved services shall be added to the Approved Services List; rejected requests shall be documented with rationale.

Identity and Access Management

Access to cloud resources shall be granted strictly on a least-privilege, need-to-know, and need-to-use basis. Personnel and service identities must not be granted broader permissions than required to perform their function.

Access shall be assigned through defined roles/groups mapped to job function, rather than through direct, ad-hoc grants to individual identities, wherever the underlying platform supports it. Standard roles (e.g., Read-Only, Developer, DevOps/Cloud Administrator, Security Auditor) shall be documented, including the permissions each role confers. Custom IAM policies should be reviewed by Information Security prior to deployment to Production.

MFA shall be mandatory for all human access to cloud management consoles, VPN/bastion access, and any system providing administrative access to cloud infrastructure. MFA shall be mandatory, without exception, for root/management-level accounts and any privileged administrative identity. Hardware security keys or authenticator-app-based MFA should be preferred over SMS-based MFA where the platform supports it.

Password policies for cloud accounts shall enforce minimum length, complexity, and rotation requirements consistent with the organisation's Access Control Policy, or, where supported, passwordless/FIDO2 authentication. Single Sign-On (SSO) integration with a centrally managed identity provider should be used for cloud console and application access wherever supported.

Privileged accounts shall be individually attributable — shared or generic privileged accounts are prohibited except where technically unavoidable, in which case compensating controls shall apply. Use of a Privileged Access Management (PAM) solution or credential vault is recommended for storing and brokering privileged credentials. Privileged sessions should be logged and, where risk warrants, recorded for audit purposes.

Human user identities and machine/service identities shall be provisioned and managed separately. Service identities shall be scoped to the minimum permissions required by the specific workload and must not be used interactively by human users. Long-lived static credentials for service identities should be avoided in favour of short-lived, automatically rotated credentials wherever the platform supports it.

Access to cloud accounts, environments, and privileged roles shall be reviewed at least quarterly by resource/data owners and Information Security. Access for terminated employees or contractors shall be revoked within 24 hours of last working day. Access review outcomes, including revocations, shall be documented and retained as audit evidence for a minimum of 1 year.

Access provisioning shall follow a documented request-and-approval workflow, requiring approval from the resource owner and/or manager. Deprovisioning shall be triggered automatically or promptly upon role change, transfer, or termination, and shall cover all cloud accounts, VPN, and related credentials.

Elevated or emergency access shall be time-bound, logged, and subject to post-use review. Just-in-time privilege elevation mechanisms should be used in preference to standing administrative access wherever supported by the platform.

The cloud provider root/management account shall not be used for day-to-day operations. The root account shall be protected with MFA, and its credentials shall be securely stored with access restricted to a minimal, named set of authorised senior personnel. Use of the root account shall generate an alert to Information Security, and each use shall be reviewed.

Access keys, API keys, and other long-lived credentials shall be inventoried, rotated on a defined schedule (e.g., every 90 days), and revoked immediately upon suspected compromise. Unused credentials and inactive IAM identities shall be identified and disabled/removed on a periodic basis. Credentials must never be embedded in source code, configuration files, or container images.

Network Security

Cloud workloads shall be deployed within logically segmented virtual networks (e.g., VPCs), with subnets separated by function (e.g., web/application/data tiers) and by environment. Segmentation shall be designed to contain the impact of a compromise within a single segment wherever feasible.

Resources that do not require direct internet access (e.g., databases, internal services) shall be deployed in private subnets with no direct route to the internet. Only resources with an explicit business requirement for public accessibility (e.g., public-facing load balancers, web front-ends) shall be placed in public subnets.

Security group and firewall rules shall follow the principle of least privilege — default-deny inbound, with explicit allow rules scoped to specific ports, protocols, and source ranges. Broad allow rules (e.g., 0.0.0.0/0 on administrative ports such as SSH/RDP) are prohibited. Security group configurations shall be reviewed periodically to identify and remove overly permissive or unused rules.

Network ACLs should be used as a defence-in-depth control at the subnet level, complementing security-group-level controls, where the cloud platform supports them.

Direct administrative access (SSH/RDP) to cloud compute resources from the public internet is prohibited. Administrative access shall be routed through a bastion host, VPN, Session Manager/SSM-type service, or equivalent secure access broker, with MFA and logging enabled.

Where remote administrative access is required, Legistify shall provide a corporate VPN or cloud-native session-management service, requiring MFA and issuing time-bound, logged sessions.

Periodic external attack-surface reviews shall be performed to identify unintended public exposure of resources (e.g., open storage buckets, exposed management ports, exposed databases). Any newly identified unintended exposure shall be remediated on an emergency basis.

All external-facing services shall enforce HTTPS/TLS (TLS 1.2 or higher) for data in transit; plaintext HTTP shall be disabled or redirected to HTTPS. TLS certificates shall be issued by trusted certificate authorities, monitored for expiry, and renewed prior to expiration.

Internal service-to-service communication should be encrypted in transit wherever the sensitivity of the data or the architecture warrants it, and API calls between internal microservices should be authenticated.

Internet-facing applications should be protected by a Web Application Firewall (WAF) configured with rules addressing the OWASP Top 10 and known attack patterns. DDoS protection capabilities offered by the cloud provider should be enabled for internet-facing production services, where applicable.

Data Protection

All data processed or stored within Legistify's cloud environment shall be classified in accordance with the organisation's Data Classification Policy (e.g., Public, Internal, Confidential, Restricted/Sensitive Personal Data). Classification shall drive the applicable encryption, access control, retention, and handling requirements.

All storage services holding Confidential or Restricted data (object storage, block storage, managed databases, backups, and snapshots) shall have encryption at rest enabled using provider-managed or customer-managed encryption keys. Encryption at rest should be enabled by default for all storage resources, regardless of classification, as a baseline control.

Data classified as Confidential or Restricted must be encrypted in transit using TLS 1.2 or higher, both for external communication and, where feasible, for internal service-to-service communication.

Cryptographic keys shall be managed through a managed key management service (e.g., AWS KMS or equivalent), with defined key owners, access policies, and rotation schedules. Access to key management operations (create, disable, delete, grant) shall be restricted to authorised personnel and logged. Key rotation should occur on a defined schedule unless a documented business or technical reason requires otherwise.

Secrets (e.g., API keys, database credentials, encryption keys, service account tokens) shall be stored in a dedicated secrets management solution (e.g., AWS Secrets Manager, HashiCorp Vault, or equivalent). Secrets must never be hardcoded in source code, configuration files, container images, or CI/CD pipeline definitions. Secrets shall be rotated on a defined schedule and immediately upon suspected compromise. Access to secrets shall be logged and restricted to the identities that require them.

Object storage (e.g., S3 buckets or equivalent) shall have public access blocked by default, with any exception requiring documented business justification and approval. Access logging shall be enabled on storage holding Confidential or Restricted data. Lifecycle policies shall be configured to manage object retention and deletion.

Legistify shall not transfer or replicate data classified as Confidential or Restricted to cloud regions or provider infrastructure in jurisdictions that do not meet Legistify's data residency requirements or applicable regulatory obligations without prior approval from Information Security and, where required, Legal.

Personal data processed in Legistify's cloud environment shall comply with the DPDP Act, 2023, and any other applicable jurisdiction-specific requirements, in coordination with Legistify's Data Privacy Policy. Personal data shall be retained only as long as required by business need or regulatory obligation and deleted securely at the end of its retention period. AI/ML models or services that process personal data must be assessed for privacy impact prior to deployment.

Container and Serverless Security

Container images shall be built from minimal, hardened base images and must not include unnecessary packages, tools, or credentials. Images shall be scanned for known vulnerabilities (CVEs) prior to deployment and on a recurring schedule; images with critical/high vulnerabilities must not be deployed to Production without an approved exception. Container images shall be stored in a private, access-controlled registry; use of public or unverified images is prohibited without security review and approval. Image builds should be reproducible and version-tagged; use of unversioned or "latest" tags in Production is discouraged.

Containers shall run as non-root users and with read-only file systems where technically feasible. Secrets shall be injected at runtime from a secrets manager and must never be baked into container images. Network policies shall be applied to restrict inter-container/inter-pod communication to what is required. Container orchestration platforms (e.g., Kubernetes/EKS) shall be configured with security hardening applied, including RBAC, pod security standards, and audit logging.

Serverless functions shall follow the same least-privilege IAM principles as other workloads, with execution roles scoped to only the permissions required by the specific function. Function dependencies shall be kept minimal and scanned for vulnerabilities. Sensitive data must not be logged by serverless functions; environment variables must not contain plaintext secrets.

Application and API Security

Applications deployed on Legistify's cloud infrastructure shall be developed in accordance with Legistify's Secure Development Policy and relevant OWASP guidance. Security testing (SAST, DAST, dependency scanning) shall be integrated into the CI/CD pipeline as a quality gate for Production deployments.

All public and internal APIs shall 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 shall be enforced on all API endpoints; insecure direct object references, injection attacks, and other OWASP API Security Top 10 risks must be mitigated. Sensitive data (e.g., PII, credentials) must not be included in API responses beyond what is required, and must not be logged in plaintext.

Monitoring, Logging, and Alerting

Logging shall be enabled, at minimum, for the following across all Production cloud accounts:

Logs shall be centralised in a dedicated log aggregation service or account, separate from the accounts/resources they monitor, to protect integrity. Log retention periods shall be defined per log category based on operational, security, and regulatory/contractual requirements. Logs shall be protected against unauthorised modification or deletion, and access to raw logs shall be restricted to authorised Information Security and Cloud Engineering personnel.

Alerting thresholds and escalation paths shall be defined for critical events (e.g., root account use, security group opened to the internet, disabled logging, repeated authentication failures), with alerts routed to the responsible on-call/Information Security function in near real time. All actions performed by privileged/administrative identities shall be logged and subject to periodic review.

Backup and Disaster Recovery

All Production systems and data classified as Confidential or Restricted, and any system deemed business-critical, shall be backed up in accordance with a documented backup schedule.

Backups shall be encrypted using the same or equivalent key management standards as their source data, and retained per the schedule above. Restoration procedures shall be tested periodically to validate that backups are recoverable and that recovery time objectives can be met. Test results shall be documented, and any gaps identified shall be remediated.

Legistify shall maintain a Disaster Recovery (DR) Plan covering critical systems, defining failover procedures, roles and responsibilities, and communication protocols. The DR Plan shall be tested at least annually through a tabletop exercise or live failover test, with results documented and gaps tracked to closure.

Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) shall be defined per system/application, based on business criticality, and documented in the DR Plan. Production systems classified as business-critical should be designed for high availability (e.g., multi-AZ deployment, auto-scaling, load balancing, health-check-based failover) to minimise single points of failure.

Vulnerability and Patch Management

Cloud infrastructure, container images, and applications shall be scanned for vulnerabilities on a recurring, automated basis, in addition to periodic penetration testing. Operating systems, middleware, and application dependencies shall be kept current with vendor-released security patches, following a documented patch management schedule that includes testing prior to Production deployment where feasible.

Vulnerabilities shall be remediated within the following risk-based timelines:

Cloud Engineering and Information Security shall monitor security advisories from the cloud provider(s), operating system vendors, and key software/library maintainers on an ongoing basis. Remediation priority shall consider not only CVSS/vendor severity but also exploitability, exposure (internet-facing vs. internal), and the sensitivity of data associated with the affected system. Where a vulnerability cannot be remediated within the defined timeline, an exception shall be raised, assessed, and approved in accordance with the Policy Exceptions section, with compensating controls applied and the exception tracked to closure.

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. Indicators may include unauthorised access, anomalous API activity, data exfiltration indicators, malware detection, denial-of-service activity, or unauthorised configuration changes.

Incidents shall be classified by severity (Critical, High, Medium, Low) with corresponding target response and escalation timelines defined in Legistify's Incident Response Plan. 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, including applicable Annex A controls related to cloud security, access control, cryptography, operations security, and supplier relationships. Controls described in this Policy are also designed to support the Trust Services Criteria relevant to SOC 2 (Security, Availability, and where applicable, Confidentiality and Privacy).

Cloud processing of personal data shall comply with applicable data protection and privacy laws, including the DPDP Act, 2023, and any other jurisdiction-specific requirements applicable to Legistify's customers. Where customer contracts impose specific security, data residency, retention, or audit requirements, those requirements shall be identified, tracked, and incorporated into the relevant cloud environment's configuration and operational procedures.

Legistify shall review and maintain evidence of its cloud providers' relevant compliance certifications and attestations (e.g., ISO 27001, SOC 2) as part of vendor due diligence. 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 provider, as outlined below:

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 shall be performed, covering the vendor's security certifications, data handling practices, and incident history where available. AI/ML managed services (e.g., AWS Bedrock or equivalent) shall undergo additional review of data usage, model training practices, data residency, and guardrail/PII controls prior to adoption.

Third-party and managed service providers shall be contractually required to maintain security controls commensurate with the sensitivity of the data they process, including encryption, access control, and breach notification obligations. Access granted to third-party providers shall be scoped to the minimum necessary, time-bound where appropriate, and reviewed on the same cadence as internal access reviews.

Data shared with third parties shall be classified, and appropriate contractual and technical safeguards shall be in place prior to data transfer. The availability, performance, and security posture of critical third-party/managed services shall be monitored on an ongoing basis. Contracts with cloud and third-party service providers should include, where applicable, security requirements, audit rights, data protection clauses, breach notification timelines, and defined data residency and deletion obligations.

Upon termination of a vendor relationship, Legistify shall ensure timely revocation of access, retrieval or confirmed deletion of Legistify data held by the vendor, and documentation of the offboarding activities completed.

Cloud Cost and Resource Management

Secure Configuration and Hardening

The following baseline controls shall apply across resource classes:

Policy Exceptions

Where strict compliance with a requirement of this Policy is not achievable due to a genuine technical or business constraint, an exception may be granted subject to the following process:

Roles & Responsibilities

Policy Revision History