Security practices designed for institutional trust

1. Overview

Stackle requires all authorised users to exercise a duty of care in the operation and use of its information systems. Beyond information published for public consumption, access is expected to be formally authorised and handled with regard to the rights, sensitivities, and security obligations attached to institutional and learner data.

This overview brings together the practical security commitments reflected across Stackle's privacy, breach-response, and governance materials so institutions can review them in one place.

The emphasis is straightforward: protect access, encrypt stored and transmitted data, limit who can touch sensitive systems, retain evidence when incidents occur, and provide institutions with clear paths for privacy, security, and incident questions.

2. Infrastructure and Encryption

Stackle's production environment is described in the privacy materials as hosted on Laravel Cloud using Amazon Web Services in the Asia-Pacific Sydney region. This keeps the primary production data location in Australia and aligns with the jurisdictional expectations of many higher education institutions operating locally.

The storage and delivery stack emphasises encrypted infrastructure and transport-layer protection rather than vague claims about enterprise readiness.

3. Access Control, Authentication, and Monitoring

Access to personal data within Stackle is limited to authorised personnel who need that access to perform their role. The security posture described across the privacy and breach-response materials is layered: identity controls, session controls, rate limiting, bot protection, monitoring, and auditable operational response.

For institutions using Stackle inside an LMS, access also benefits from the platform's LTI-based operating model, which keeps activity inside the institutional learning environment rather than routing users through unnecessary external workflows.

4. Data Handling, Ownership, and AI Use

Stackle's published privacy position is clear that organisations remain central to the control context around user data. The platform acts as a data processor on behalf of institutions that deploy it, while direct website interactions are handled by Stackle as controller.

Stackle's public AI position supports a straightforward principle: institutional content should not be quietly repurposed for model training, and any enabled provider should sit within explicit organisational control.

5. Resilience, Logging, and Incident Response

Security is not just about keeping systems locked down. It is also about being able to detect problems early, contain them quickly, preserve evidence, restore service safely, and notify the right people when thresholds are met.

Stackle's data breach policy provides the strongest operational detail here. That document outlines a virtual incident team, severity classifications, containment windows, notification rules, a central breach register, and post-incident review expectations.

6. Compliance Position and Security Questions

Stackle's published materials already align with several of the expectations institutional buyers look for on a security page: Australian Privacy Act and APP-aware handling, GDPR-aware rights and notification processes, documented breach response, controlled cookies, encryption, and layered access protection.

Institutions often want a concise overview, clear statements about ownership and training use, and a direct path for detailed security questions. That is the role of this overview, backed by the underlying privacy, breach, and trust-centre materials.