Content Comparison

Primary place for legal claims to be made by the Parties

England and Wales

The status of the Exporter : (In relation to the Processing of the Transferred Data)

Exporter is a Controller

The status of the Importer : (In relation to the Processing of the Transferred Data:)

Importer is the Exporter’s Processor or Sub-Processor

Whether UK GDPR applies to the Importer:

UK GDPR applies to the Importer’s Processing of the Transferred Data

Linked Agreement

The Cloud EULA accepted through subscription

Term

The term of the subscription

Ending the IDTA before the end of the Term

The Parties cannot end the IDTA before the end of the Term unless there is a breach of the IDTA or the Parties agree in writing

Ending the IDTA when the Approved IDTA changes

neither Party

Can the Importer make further transfers of the Transferred Data?

The Importer MAY NOT transfer on the Transferred Data to another organisation or person (who is a different legal entity) in accordance with Section 16.1 (Transferring on the Transferred Data)

Specific restrictions when the Importer may transfer on the Transferred Data

there are no specific restrictions

Review Dates

Every 7 years. Data may be retained only through support tickets/email history for historic purposes and will be periodically culledWe retain support data for 7 years to help us understand problems that customer have had historically. We execute periodic purges of such old data. Customers can ask for supplied data to be removed at the closure of a support case, which be handled on a case by case basis.

Security of Transmission

Our support system uses secure HTTPS transport

‘flagged’ support emails are made using secure HTTPS transport

Security of Storage

Data supplied in support is secured by the Jira platform, Data ‘flagged' is secured by the JEMHC production application which uses encryption at rest

Security of Processing

Full time employees participate in support and have access to ‘flagged’ data. Customer data is processed locally and on remote Jira instance sites. Data can also be reprocessed through external services as part of support. secure HTTPS transport is used at all times for such transfers

Organisational security measures

We use 2fa for Jira account security and access to ‘flagged’ data

Technical security minimum requirements

Access is limited to authorized named employees who are subject to a role based permissions policy

Data is encrypted at rest (applies to webhooks, raw emails in/out)

Field level encryption is used for sensitive values

Updates to the Security Requirements

The Security Requirements will update automatically if the information is updated in the Linked Agreement referred to

(i) Extra technical security protections

2 factor authentication wherever possible

The deployment works on a least privilege basis with group access policies for different environments (DEV/UAT/PROD)

Outbound SMTP mail must use TLS or SSL

Inbound POP/IMAP mail retrieval must use SSL

Mail stored as part of auditing is purged by policy after 30 days

Webhook ‘event’ data is purged by policy after 7 days to allow for review by customer and avoid data loss in cases where the monthly Capacity Plan is consumed or Plan Upgrade lapses, ie customer has 7d to purchase more capacity before webhook data will be lost.

A ‘dead end’ mailhost is used for consuming mail sent during testing with customer supplied email data to ensure no data can ‘leak’ to actual recipients.

Support closure requires JEMHC support staff to confirm via checkbox that local copies of data from support/flagged mail have been purged.

MS Windows is not used for development

(ii) Extra organisational protections

Access to cloud development environment is limited to cloud team only, named users

(iii) Extra contractual protections

none