Aula Education Ltd

Digital Communication Platform for Higher Education

Aula is a communication platform which brings engagement to the core of the digital student experience, replacing the virtual learning environment. We partner with universities to transform course content and harness behaviour data to drive engagement, enabling incredible teaching and learning to happen in every class, every time.


  • Enable intuitive communication through course-wide posts and instant messaging.
  • Organise course material and assignments.
  • Automatically populate students, educators and spaces through an SRS integration.
  • Interact through posts, comments, messages and reactions (emojis).
  • Integrate content, file-storage (e.g OneDrive) & assessment (e.g. Turnitin).
  • Communicate using, images, video, voice-recording, code, LaTeX, and embedded integrations.
  • Make announcements and send reminders.
  • Native iOS and Android mobile apps.
  • Ongoing change-management support from our Learning Intelligence team


  • Saves academics’ time by streamlining communication and reducing task duplication.
  • Substantially increases student engagement compared to traditional VLE/LMS alternatives.
  • Results in positive student feedback around learning experience and community.
  • Makes collaboration and cross-departmental work easier by connecting all students.
  • Addresses key causes for non-continuation through building communities.
  • Supports widening participation through spaces that are accessible from anywhere.
  • Gives competitive advantage in recruitment by using consumer standard technology.
  • Supports employability by mirroring modern workplace software.


£24 per user per year

  • Education pricing available

Service documents


G-Cloud 11

Service ID

9 6 1 9 7 5 4 3 4 2 0 3 0 9 0


Aula Education Ltd

Anders Krohn


Service scope

Software add-on or extension
Cloud deployment model
Public cloud
Service constraints
System requirements
Internet connection

User support

Email or online ticketing support
Email or online ticketing
Support response times
Under 30 minutes for first response. No difference on weekends.
User can manage status and priority of support tickets
Phone support
Phone support availability
9 to 5 (UK time), Monday to Friday
Web chat support
Web chat
Web chat support availability
24 hours, 7 days a week
Web chat support accessibility standard
WCAG 2.1 AA or EN 301 549
Web chat accessibility testing
Onsite support
Onsite support
Support levels
We provide two different types of support for our customers, at no extra cost.

Technical Support: We provide reactive user support, as well as bespoke technical account manager support for administrators.

Pedagogical Support - We supply bespoke support for all educators on the use of platform to support student outcomes.
Support available to third parties

Onboarding and offboarding

Getting started
To implement the product, we have our highly specialised implementation/learning intelligence team. They add all capacity necessary for the implementation to be a success. This includes full onboarding, workshops with all educators, inductions for students, and continuous, proactive feedback and support, through in person meetings or calls and user documentation as required.

The platform itself has some online training within the platform.
Service documentation
Documentation formats
End-of-contract data extraction
Through EBV volume snapshot and transfert or through mongodump in an S3 bucket.
End-of-contract process
In the price of the contract includes full use of the platform, including updates (at the scope agreed in the Statement of Work) and full Learning Intelligence support. This ends at the end of the contract. There are no additional costs.

Using the service

Web browser interface
Supported browsers
  • Microsoft Edge
  • Firefox
  • Chrome
  • Safari 9+
  • Opera
Application to install
Compatible operating systems
  • Android
  • IOS
  • Linux or Unix
  • MacOS
  • Windows
Designed for use on mobile devices
Differences between the mobile and desktop service
Aula has been designed as a web platform (browser and desktop app) and a mobile iOS and Android app. The majority of the functionalities that exist on the web version are also available on the mobile applications. In most cases, the usage from a student perspective is higher on mobile.

There are slight differences between web and mobile for example through edit functionalities, but fundamentally Aula has been designed for mobile first use cases.
Service interface
Description of service interface
We have public facing APIs and use a federated SSO for authentication.
Accessibility standards
WCAG 2.1 AA or EN 301 549
Accessibility testing
What users can and can't do using the API
Aula provides a standard REST API for its users, spaces, roles and services.

They can make changes by doing a post request, and there are no limitations to how users can set up or make changes.
API documentation
API documentation formats
Open API (also known as Swagger)
API sandbox or test environment
Customisation available


Independence of resources
Aula uses Terraform ('Infrastructure as Code') to provide each institution with a dedicated environment, that has its own separate networks, servers and database.


Service usage metrics
Metrics types
Regular reporting direct to customer and real-time dashboard serviced through an API which we use to create the reporting.
Reporting types
  • API access
  • Real-time dashboards
  • Regular reports
  • Reports on request


Supplier type
Not a reseller

Staff security

Staff security clearance
Conforms to BS7858:2012
Government security clearance
Up to Baseline Personnel Security Standard (BPSS)

Asset protection

Knowledge of data storage and processing locations
Data storage and processing locations
Other locations
User control over data storage and processing locations
Datacentre security standards
Complies with a recognised standard (for example CSA CCM version 3.0)
Penetration testing frequency
At least every 6 months
Penetration testing approach
Protecting data at rest
Encryption of all physical media
Data sanitisation process
Data sanitisation type
Deleted data can’t be directly accessed
Equipment disposal approach
In-house destruction process

Data importing and exporting

Data export approach
The data is owned by the university and we use data that they can already access.
Data export formats
Other data export formats
Data import formats
Other data import formats

Data-in-transit protection

Data protection between buyer and supplier networks
TLS (version 1.2 or above)
Data protection within supplier network
TLS (version 1.2 or above)

Availability and resilience

Guaranteed availability
To achieve high availability, our server deployment span across two AWS availability zones.
Approach to resilience
Aula routinely carries out tests of its Business Continuity Arrangements on a monthly basis by refreshing pre-production environments (e.g. Beta and Test environments) with data from archives located in a geographically discrete location. If three or more Test Implementation failures occur in a 12-month period, we will inform the institutions of the failure and any planned responses.

Aula uses a microservice architecture with multiple levels of failure handling:
Process level: if a process dies inside of a container it is instantly restarted
Container level: if a container dies or becomes unresponsive it is restarted automatically by our orchestrator
Machine level: if a machine dies (disk, network…) it is automatically replaced by another instance in our clusters.

Every service is redundant (at least 2 copies), machines are distributed across AZs (availability zones) and are being monitored for failure.

Failure is a process that we embrace and recover transparently from.
Users are mostly never affected by failures in the system.
Outage reporting
Email alerts shared directly with project board, service desk and relevant senior academic stakeholders, followed by comms to wider academic community once approved by relevant stakeholders.

Identity and authentication

User authentication needed
User authentication
Identity federation with existing provider (for example Google Apps)
Access restrictions in management interfaces and support channels
We have 3 roles: educator, student and admin.

Students have read access for space data and write access for their own (e.g. they can't delete or edit other people's content, or edit class material).
Educators have read and write access for a given space (can edit class material, can delete any post or comment).
Admin can manage users and spaces.
Access restriction testing frequency
At least every 6 months
Management access authentication
Public key authentication (including by TLS client certificate)

Audit information for users

Access to user activity audit information
Users contact the support team to get audit information
How long user audit data is stored for
Between 1 month and 6 months
Access to supplier activity audit information
Users contact the support team to get audit information
How long supplier audit data is stored for
Between 1 month and 6 months
How long system logs are stored for
Between 1 month and 6 months

Standards and certifications

ISO/IEC 27001 certification
ISO 28000:2007 certification
CSA STAR certification
PCI certification
Other security certifications
Any other security certifications
CyberEssentials Plus

Security governance

Named board-level person responsible for service security
Security governance certified
Security governance standards
  • ISO/IEC 27001
  • Other
Other security governance standards
AWS is ISO/IEC 27001 compliant.
Information security policies and processes
Our CTO Oliver is responsible for maintaining Aula's security policies. He is also responsible for training staff on our security practices. Every line of code is secure using up-to-date industry standard techniques, including static code analysis for every line in production.

Operational security

Configuration and change management standard
Supplier-defined controls
Configuration and change management approach
Every major changes in the environment (infrastructure and code) that could affect the institution's security posture are communicated immediately to the institution. In order to enable the best user experience and to make sure that the latest security fixes are applied, every institution is running the latest version of the Aula platform. Emergency changes are always documented in a github issue, then reviewed and approved before deployment as any other production code.
Vulnerability management type
Supplier-defined controls
Vulnerability management approach
We use ESLint and Snyk to scan for vulnerabilities in our applications and systems, as well as using strict data validation on the server side.
Every line of code is secure using up-to-date industry standard techniques, including static code analysis for every line in production.
Critical patches on Aula's code are deployed as soon as it is discovered and fixed. Critical patches on our host machines are applied every 36h at most.
Protective monitoring type
Supplier-defined controls
Protective monitoring approach
We use DDos detection and mitigation. We also use a monitoring service based on the tick stack and alerting on suspicious activities.
We use the AWS services 'X-Ray' and 'Inspector' to detect intrusion.
We respond to incidents instantaneously by taking the affected service offline immediately and working on it straight away.
Incident management type
Supplier-defined controls
Incident management approach
All errors are flagged to the end-user directly and all errors are logged. Errors are available to every admin directly through Kibana. All major incidents reported are responded to immediately.

Secure development

Approach to secure software development best practice
Conforms to a recognised standard, but self-assessed

Public sector networks

Connection to public sector networks


£24 per user per year
Discount for educational organisations
Free trial available

Service documents

Return to top ↑