Messenger v5 Data Security Summary


This document applies to Groupcall Messenger v5, for all supported MIS systems.

Version Information

  Date Author Notes
1 11/09/2012 Tim Verlander  
2 24/09/2012 Tim Verlander Changes highlighted by Technical review 
3 05/10/2012 Stuart Abramhs Clarifications, 'real-time' data requests

Table of Contents

Protection of Data in Flight – MIS Data

Importing data into Messenger v5 varies by MIS and upload route;

Cloud hosted MIS products

For supported cloud-based MIS products Messenger v5 can integrate directly to retrieve school data. For the purposes of simple explanation to all customers we describe such integration as “cloud-to-cloud”.

Messenger v5  supports “cloud-to-cloud” integration with the following systems:

MIS Product Credential School Identifier School Credential  Granular Data Access Permissions
Pearson e1 No Yes Yes No
RM Integris G2/S2 Yes Yes Yes No
Serco Progresso Yes Yes Partial - Serco progresso requires schools to permit Groupcall products to access their specific school identifier. Yes
Bromcom MIS (cloud) Yes Yes Yes Yes


For “cloud-to-cloud” integration Messenger v5 requires the cloud MIS to be configured to enable third party integration; this usually requires the customer to enter into additional data sharing agreements with their MIS provider and may also incur a one-off or recurring cost for the service levied by the MIS vendor.Messenger v5 requires credentials and/or settings to access a cloud MIS for integration.  These credentials and/or settings can include:

  • Messenger v5 product credentials used to identify the product to a Cloud MIS; usually this provides a first tier of protection for the Cloud MIS by only allowing registered products to make authentication challenges for specific schools.  Such credentials are typically hard-coded into the Messenger v5 application.
  • Per-school integration settings and credentials are then used to verify that Messenger v5 can request data for a specific school.  Depending on the Cloud MIS these credentials may imply finer controls on what data Messenger v5 can access.  Such credentials and settings are stored in Messenger v5's back-end storage.

Transfer and processing

Groupcall require that any data transfer from a Cloud MIS is carried out over SSL so that the data is protected in flight and so that Messenger v5 can verify the destination system prior to presenting any credentials.Some Cloud MIS products require that Messenger v5 requests a larger dataset than is required, for example it may be the case that a Cloud MIS can only provide a list of students that also includes their postcode.  In all cases of Cloud MIS integration, data is processed immediately on response (i.e. it isn’t cached or queued anywhere) and any additional fields received are discarded from memory during that processing.

School hosted MIS products

For supported in-school MIS systems, we use our Groupcall Xporter software to extract the required school data from your MIS system and upload it securely to Messenger v5.Messenger v5 supports integration using Groupcall Xporter for the following systems:

MIS Nature of connection Credential type Granual Data Access Permissions
Capita SIMS .net SIMS .net libraries SIMS user Yes
Serco Facility ODBC / ePortal SQL user / source IP No
Double First Engage ODBC SQL user No
Follett Aspen ODBC SQL user No
Bramcom MIS (local) SOAP API Bromcom user No


For Xporter-based integration with an MIS Groupcall Xporter has to be installed in the school, usually on the MIS server. Xporter then requires configuration settings and/or credentials to access the MIS and retrieve data to prepare for upload to Messenger v5. Groupcall Xporter securely encrypts MIS credentials into its configuration using industry standard Blowfish encryption. This encryption is reversible because Xporter must be able to present credentials to the MIS in the format it requires.The exact nature of the connection method varies by MIS product; however this is explained under MIS specific details. Integration may also incur a one-off or recurring cost for the service levied by the MIS vendor.

Transfer and processing

Groupcall Xporter extracts data from the school MIS on an hourly schedule between 7am and 5pm and uploads to Messenger v5, this process usually takes only a few minutes and only records that have changed since the previous upload will be transmitted. For exact detail of the fields transmitted see the Messenger v5 Data Sharing Agreement.All uploads to Messenger v5 are carried out over SSL both to protect data in flight and to verify the destination system prior to presenting data. Data is delivered to the correct customer account in Messenger v5 by use of a per-school upload “key” stored in Xporter. The upload key, which is a GUID, does not provide a means to extract data from Messenger v5 and as such is not considered to be a secret or a credential.Data is processed immediately upon receipt into the Messenger v5 platform; by virtue of Xporter pre-processing records in the school only fields within the limitations of the data sharing agreement are transmitted.

Manually integrated MIS products

For a small number of MIS products Messenger v5 is unable to integrate directly, this can be for a number of reasons including the availability of integration options, the security of them, or an agreement with the MIS provider. For customers using these MIS products we support more manual forms of integration.Messenger v5 supports manual integration with the following systems:

MIS Integration Method
SEEMIS Click 'n' Go The customer must upload Format1 exports of Contacts and Attendance


The specific pre-requisites vary by MIS, however it typically involves the user producing a consistent data export from their MIS and temporarily saving it to their workstation.

Transfer and processing

For these customers the MIS export must then be uploaded into the Messenger v5 website by an authorised user account for that customer. The upload is carried out over SSL and cached during processing in Messenger v5 then deleted after processing. Where the uploaded export contains columns that exceed the data requirement these columns are dropped during the import process. The import process is asynchronous to the return webpage sent to the client on upload.

SIF enabled data sources

Messenger v5 is able to act as a SIF subscriber, both in requesting data and subscribing to SIF events, for systems that can present data via the SIF standard. The nature of the SIF provider agent and the Zone Integration Server (ZIS) that brokers communication between Messenger v5 and the provider agent is outside of the scope of this document, although it can be noted that Groupcall provides SIF Agents for a number of leading UK MIS products.Messenger v5 supports integration with any SIF agent conforming to the UK 1.2 data model and supporting the following objects with sufficient element coverage.

  • SchoolInfo
  • ContactPersonal
  • WorkforcePersonal
  • SchoolGroup
  • LearnerAttendance
  • PersonPicture
  • LearnerPersonal
  • LearnerContact
  • SchoolGroupType
  • LearnerGroupEnrolment
  • LearnerAttendanceSummary


The precise nature of integration varies by ZIS and provider but typically the ZIS operator enforces the Data Sharing Agreement on behalf of the end customer and also authenticates the Messenger v5 agent before it is able to make requests.Messenger v5 will only communicate with a ZIS using SSL and only if the destination system can be verified by its SSL certificate.For these customers details of the ZIS URL are stored in Messenger v5 in the same manner as integration settings for a Cloud-based MIS.

Transfer and processing

Messenger v5 connects into the ZIS and subscribes to events for the data source; it then requests data nightly and requests attendance hourly during school hours. The provider agent responds with SIF objects that are processed immediately upon receipt.Where the provider agent sends events on data changes, these are processed immediately upon receipt. Any events or fields received that are outside the scope of the data sharing agreement are disposed of during processing. 

Custom Contacts
It is possible for Messenger v5 customers to enter their own custom contacts directly into the Messenger v5 user interface, to supplement those contacts being collected from the MIS. The Messenger v5 user interface is presented over SSL and requires user authentication, hence protecting the ‘transfer’ of these contacts as they are entered into the website.

Protection of Data in Flight – Messages

Delivery of directed messages and responses

For the following methods of communication Messenger v5 uses industry standard systems to achieve message delivery.

  • SMS (text) messages
    • Broadcast
    • Open response
    • Closed response
    • Voice messages
    • Emails

All messages, of any type, will be temporarily queued in Messenger v5 then forwarded and queued at one or more of our partner delivery companies for delivery into the appropriate delivery network (e.g. mobile phone network for SMS).  This means that the content of the message, and any response to it, will be queued and forwarded by a number of different systems as would any message not originating from Messenger v5, hence the same risks apply as for any other message sent by these methods.

SMS, Voice and Email are generally accepted not to be secure forms of communication, both in terms of interception and recipient verification.  For this reason, Groupcall does not encourage the transmission of any sensitive information via these methods.  Messenger v5 cannot determine whether messages contain any personal information and responsibility for message content must rest with the end user.

Message responses – i.e. replies returned by recipients of closed or open response messages –are queued and forwarded through the message delivery networks then pushed to Messenger v5 by our partner delivery companies.  These messages are queued in Messenger v5 briefly before the response is associated to the outgoing message.

Delivery of broadcast messages

For the following methods of communication Messenger v5 uses the publicly available API integration for each specific system listed:

  • Twitter

In order to achieve API integration with these systems it is necessary to store API credentials into Messenger v5 and these are stored in the same way as Cloud hosted MIS credentials.  When connecting to the API to publish broadcast messages in this way Messenger v5 uses SSL encryption to verify the destination system prior to transmitting both the credentials and the broadcast message.

Clearly anything published in such a manner is deemed to be in the public domain and hence Groupcall strongly discourages the publication of anything but generic information (such as school closures) using this method.  Messenger v5 cannot determine whether messages contain any personal information and responsibility for message content must rest with the end user.

Protection of Data in Flight – Attendance Writeback

For selected MIS products Messenger v5 can allow authorised users to update attendance marks for students. For example if a teacher records an Unknown Absence in the MIS during electronic registration the school may then text the parental contacts to investigate further; during the process a parent may reply that the student is ill and has gone to the doctors. As a matter of convenience, Messenger v5 allows authorised users to then read such responses and record attendance mark changes within Messenger v5 to reflect the actual absence reason. In this example an authorised user in Messenger v5 may elect to update the Unknown Absence mark to an Illness mark, and this would then be updated in the MIS for historic record and for extraction by any other system that reads MIS data.

This functionality is supported only on selected MIS products; specific products that Messenger v5 can write back to are listed in the sub-sections below.

The right to update attendance is individually assigned to users within Messenger v5 and any organisation may choose to assign, or not to assign, that right to any or all of their users in accordance with that organisations own operating policies.

Writeback of changed attendance marks – Cloud hosted MIS products

For selected cloud-based MIS products Messenger v5 writes directly back to the MIS using the same secure and authenticated cloud-to-cloud transfer method as used to obtain the school data initially.

Currently this feature is not supported on any cloud-based MIS products.

Writeback of changed attendance marks – school hosted MIS products

For selected school-based MIS products Messenger v5 queues a writeback request in Messenger v5 and then sends notification to the school Xporter using a separate platform called Groupcall Dashboard. The Groupcall Dashboard platform is used to monitor and manage Xporter installations globally and to send them repair instructions. The writeback notification is then picked up by the school Xporter installation typically within 5 – 10 minutes of being queued. The details of what to write back are not passed via the Groupcall Dashboard platform, just that there is something to do.

The Xporter installation then connects to the Messenger v5 platform using SSL to pick up details of the writeback records waiting, identifying itself with its API Key. A typical writeback request will consist of non-personal information, such as:

  • The School MIS record ID for the learner
  • The mark to be written back
  • The time-point of the mark, e.g. Date and Session

The Groupcall Dashboard platform is deployed into the Microsoft Windows Azure Cloud Platform in the same fashion as Messenger v5 and is hence subject to the same stringent security considerations.

Currently this feature is supported on the following school-based MIS products:

  • Capita SIMS .net

Writeback of changed attendance marks – SIF-enabled data sources

Messenger v5 transmits SIF_Update events to the ZIS using the same SSL protection mechanisms as for SIF_Request messages. These update events contain:

  • SIF identifiers for the learner and for the attendance period/session
  • The mark to be written back, encoded into the SIF schema
  • The time-point of the mark, e.g. Date and Session or Date and Time.

The ACL configuration at the ZIS will allow or disallow the SIF update event to be transmitted back to the source agent.

‘Real-Time’ School Data Requests

Messenger v5 supports real-time contact and attendance requests for a range of MIS products. These requests can be initiated via the Messenger v5 user interface by authorised logged in users, and the incoming data response is processed in the same way as a normal scheduled import/upload of data.

Cloud-hosted MIS products

Messenger v5 will schedule an immediate synchronisation with the Cloud-hosted MIS Depending on platform workload and MIS responsiveness this will take an amount of time to process before refreshed data is shown to the user logged into Messenger v5.

You should be aware that some MIS products apply a low priority to daytime data requests and/or return ‘cached’ data from earlier in the day.

School-hosted MIS products

As with data writeback, a request will be queued for the school in Groupcall Dashboard.  When the Xporter installation in the school picks up this action,  typically within 5 – 10 minutes of being queued, the Xporter installation will run the Messenger v5 extract after any current extractions complete and will upload after it completes running the Messenger v5 extract.  This means it may take 30 minutes or more for new data to appear in Messenger v5.

Manually integrated MIS products

Manually integrated customers are free to upload new CSV data extracted from their MIS at any time.

SIF enabled data sources

For SIF enabled data sources Messenger v5 will queue SIF_Request for the necessary data objects to the ZIS Zone URL.  When the provider agent responds to these requests they will be imported into Messenger v5.

Protection of Data During Use

Messenger v5 uses a web-based user interface that protects data and guards against unauthorised access in the following ways:

  • Industry standard SSL encryption secures and verifies the website.
    • Use of SSL encryption instructs the users browser not to cache pages.
    • Use of SSL encryption prevents proxy servers caching meaningful content.
  • Users must use individually accountable usernames and passwords to log in.
  • Users can be deactivated at any time.
  • Users are constrained to access only the schools they are associated with.
  • Users are not automatically generated, they must be explicitly and individually created.
  • Users can be constrained by assignment of rights, including the right to send messages.
  • Users can have their data view limited to only a subset of that available for their school(s).
  • The forgotten password procedure contacts the user directly and does not release any password information.
  • Messenger v5 does not have any API to allow extraction of personal information.

Protection of Data in Storage

Messenger v5 uses Microsoft Windows Azure SQL storage, located in the Europe North territory and protected by international statute.  The following are the most frequent discussion points centring on use of Windows Azure as a service delivery platform.

What provisions are in place to protect data from
unauthorised access in Azure?

Windows Azure is subject to an extensive array of physical, logical and procedural measures to protect the security, confidentiality and integrity of data.  More information is available via the Windows Azure Trust Centre (see below) but the highlights are:

  • Edge packet filtering[1] and firewalling[2] protects our virtual machine instances
  • Developer access requires mutual SSL authentication using client-specific certificates[3]
  • Limited physical access to datacentres, and strict physical disk disposal policies[4]
  • Automated and integrated security patch management[5]

Are these measures independently verified?

  • Microsoft carries out regular penetration testing to identify security flaws[6]
  • Please see the ISO27001 certification for Windows Azure[7]
  • Please see the Cloud Security Alliance STAR submission for Windows Azure[8]

Is data encrypted in storage?

Both personal information and metadata are stored in Azure SQL unencrypted.  While at first glance this may seem inconsiderate to data security there is a sound rationale for this approach.

  • Encrypting data stored in the platform would indicate an absence of trust in the Windows Azure platform.  This is not the case and Groupcall have deemed the platform to meet/exceed an adequate level of data security for the purposes of Messenger v5.  This assessment takes into account the information provided in this document and further detail from Microsoft provided documentation.

Encrypting data does not significantly reduce the risk of exposure.  In order for Messenger v5 to display contacts, deliver messages and provide history and search functionality it would be necessary for data to be decrypted when required.  If Groupcall Messenger v5 or Windows Azure were compromised then the code to achieve this decryption would also be compromised and data would effectively be unprotected despite being encrypted.

[1] - page 11
[3] - page 8
[4] - page 18


Updates to Groupcall Messenger V5

The Messenger v5 platform consists of a number of distinct components, including Messenger v5 itself, our interfaces with external systems (MIS, message delivery partners, etc), Groupcall Xporter and the Groupcall Xporter data extraction scripts for each supported MIS.

Groupcall periodically releases updates of Messenger v5 to introduce new features and to resolve identified bugs.  Groupcall takes a number of measures to validate releases of Messenger v5 before they are promoted into live; these measures begin before development and include:

  • Technical design discussion for both new features and bug fixes
  • Peer review of application code
  • Testing of new features against our local platform and then our staging platform
  • Regression testing existing features against our local platform and then our staging platform
  • Integration testing against live builds of other Groupcall Messenger v5 components

To carry out this testing we carry out the following phases in succession:

  • We test on our local platforms using sample data
  • We publish our code into Windows Azure in a staging area and test using demonstration accounts in our live datastore that are populated with sample data.

Once we are satisfied with testing and integration we ‘swap’ live and staging over so that staging becomes live.  This also means that we have the previously live code in staging, and allows us to swap back promptly if any issues are identified after cutover.  This previously live application version is then typically discarded within 48 hours of promotion unless there is reason to retain for rollback purposes for longer.

A similar testing process is applied for changes to Groupcall Xporter and Groupcall Xporter data extraction scripts for each supported MIS

  • Testing against sample MIS data
  • Piloting with a small number of consenting live schools
  • Release of update to the Xporter estate

Microsoft Windows Azure

If there are any clarifications required regarding information in this document then the below documentation provided by Microsoft will undoubtedly add clarity.

Windows Azure Security Overview
This whitepaper covers the vast majority of questions asked about the security of the Windows Azure platform.

Windows Azure Trust Centre
This website details all aspects of security, privacy and independent verification that affect the Windows Azure platform.

Global Foundation Services
This website explains more about the operation and delivery of Windows Azure datacentres.