4 GDPR reasons for automating Automatic Enrolment


We recognise that we have a responsibility to protect the data you send to us, so pensionsync has been built with trust in mind from the beginning. From our business partner’s perspective the pensionsync data integration platform should be viewed as a highly secure, highly available, and highly resilient extension of your own IT systems without the associated set-up costs and technical management overheads.

Since the transfer and processing of personal payroll and pensions data means strict compliance to government and industry regulations, we are constantly reviewing everything we engineer with the security of your data as our number one priority. This philosophy covers the basics you would expect from your own IT systems, but goes well beyond that to provide secure and resilient services and infrastructure that you would normally expect to receive from enterprise infrastructure technology giants.

The information on this web page is a carefully selected subset of the information we make available to potential customers of pensionsync. Our internal security protocols demand that we do not release precise details on our security and business continuity practises into the public domain, for obvious reasons.

If you are considering buying a data integration service from pensionsync for your business then we would be happy to share with you more information on our data security practices once a confidentiality/non-disclosure agreement has been signed. Please use this contact form to request more information from us.

Below I’ll outline at a high level our approach and views on the following key security questions:

Will Lovegrove
CEO & co-founder

In short: very secure. Our fundamental design premise is that everyone apart from you is denied access to your data, which means strongly enforcing encryption end-to-end.

Authentication and Authorisation

When you sign up through our pensionsync Developer Portal you will be issued with API keys that are only known to you. By policy and design we do not let our support staff have any kind of access to your API keys and so we will not be able to retrieve them for you if you lose them. Of course you can use the Developer Portal to generate new keys if needed.

Specifically we use

  • 1-legged oAuth1a authentication mechanism (read here why we don’t use OAuth 2 from one of the original authors of the specification)
  • HMAC-SHA1 signature validation to ensure that your secret is not transmitted, and means that even if your network was compromised, anyone ‘listening’ will not be able to forge new requests
  • Nonce (number used once) and timestamp validations to prevent replay attacks. Replay attacks are when someone attempts to resend requests that have been ‘sniffed’ on a network. Nonce works by assigning a random string to each signed request that can only be made once using the same call. It adds a useful layer of protection on top of HMAC.
  • Body hashing is an optional security technology that you can use with pensionsync to identify whether or not your data has been tampered with between your systems and the point it reaches pensionsync APIs.


We use SHA-256 (2048-bit root) SSL certificates issued by GeoTrust True BusinessID with Extended Validation to encrypt data between your environment and our servers

Processing and temporary storage

It is important to remember that we hold data only for as long as it takes to process it and provide support. That said, as soon as your data enters into pensionsync we generate a unique one-time pad key and apply AES-256 symmetric encryption to your data and store it as a document temporarily in an encrypted state. This means that each time our service is used, a unique encryption is applied to each document we store.

We also encrypt the pad key to ensure that your encrypted data is only accessible via the pensionsync platform and cannot be accessed directly from the data store even if a route could be found to the data store i.e. an internal security breach at one our infrastructure supplier’s data centre.

Yes. systemsync solutions limited (which owns and operates pensionsync) is registered with the Information Commissioner’s Office (#ZA109264) and there obliged to comply with all aspects of the Data Protection Act. We understand the principles of that Act to be:

Principle 1 - Fair and Lawful

Our terms and conditions (which must be agreed to before any person or organisation accesses pensionsync APIs) assume your organisation has the appropriate consents to process the data in the context of our pensionsync service. You must be an authorised data controller to pass data to us (in our capacity as a registered data processor).

Principle 2 - Purpose

pensionsync has been built solely and specifically for the the purpose of enabling your organisation to process the necessary and legitimate interests of individual’s personal employee payroll data to pension providers. Once the process is completed the encrypted data is securely deleted based on our retention policy.

Principle 3 - Adequacy

pensionsync processes your source PAPDIS and PASS structured data and validate it against your desired pension provider’s requirements. The PAPDIS and PASS data structures ensures that this adequacy principle is adhered to.

Principle 4 - Accuracy

pensionsync validation processes will highlight and return to you data errors where they are incompatible with your pension provider. We cannot (and should not because we are not data controllers) check the accuracy of the records you process through pensionsync

Principle 5 - Retention

pensionsync only holds your encrypted data long enough to process it and provide support, and then it is physically deleted.

Principle 6 - Rights

Acting as an on-demand data processor, pensionsync terms of use assume individual’s rights to personal data are upheld by your organisation as a data controller. In practice:
  • Subject Access Requests - due to our strict retention (deletion) policies, individual data access requests are not possible or appropriate from pensionsync.
  • Direct Marketing - pensionsync cannot and does not read or store unencrypted personal data for any other purpose. It is not possible for pensionsync to directly market to individuals identified within any PAPDIS or PASS data sets processed by the platform

Principle 7 - Security

pensionsync provides end-to-end secure and encrypted technologies to prevent your data from being compromised.

Principle 8 - International

All of our supplier’s infrastructure is located within European Economic Area countries; specifically the UK, Ireland, and the Netherlands. No unencrypted and personally identifiable data will be transferred by us out of the EEA defined countries

We are serious about implementing best practice security throughout our platform and organisation, and are pleased to announce that on the 31st March 2015 we made two significant commitments:

Independent Security Review

We engaged with NTA Monitor, a well established and independent information security specialist consultancy, to review, test, and validate all aspects of our security.

We went through a robust selection process and found NTA Monitor’s 18 years trading as an independent information security specialist, their long list of security accreditations, clear subject matter expertise in Financial Services, Pensions, and even cloud technologies were particularly impressive. In fact they have been providing similar independent security consulting services and penetration testing for The Pensions Regulator, The People’s Pension (B & CE), and The Department of Work and Pensions.

In our case we have specifically scoped the following:
  1. A technical audit of the pensionsync architecture, configurations, data flows, supplier security assurances and SLA’s, development standards, access controls and restrictions
  2. Conducting comprehensive penetration tests against the pensionsync web applications, API’s, encryption protocols, and backend environments specifically seeking out security vulnerabilities. NTA Monitor intend to use a combination of authorised and unauthorised access, utilising a battery of bespoke and manually executed tests, along with sophisticated automated penetration testing tools. This testing will also incorporate an assessment against the OWASP Top 10 web application security risks:
    1. Injection
    2. Broken Authentication and Session Management
    3. Cross-Site Scripting (XSS)
    4. Insecure Direct Object References
    5. Security Misconfiguration
    6. Sensitive Data Exposure
    7. Missing Function Level Access Control
    8. Cross-Site Request Forgery (CSRF)
    9. Using Known Vulnerable Components
    10. Unvalidated Redirects and Forwards
  3. A policy and procedures audit against Data Protection Act (DPA) compliance. Furthermore we felt that DPA compliance wasn’t enough and have requested that NTA Monitor go beyond that and conduct a gap analysis against key ISO 27001 controls.

The output of NTA’s audit and penetration tests can be made available to our prospective customers.

Architectural Review with Microsoft

Since May 2015 we have worked closely with Microsoft and their expert technical consultants who we brought in to conduct detailed architectural reviews of our platform, and later to specifically review our Business Continuity and Disaster Recovery implementations. Practically this relationship means that we have ongoing access to experts, to review what we've engineered, and suggest where appropriate architectural, scaling, resilience, DR, performance, and security optimisations can be made. We are excited to have this level of access.

Early on we evaluated the pros and cons of doing everything ourselves. You are possibly considering the same question. Going it alone gives you ultimate control but with that control comes with a significant cost. These costs aren't just about servers, but we also considered physical security, disaster recovery, and resilience. We quickly realised that purchasing servers, racks, firewalls, load balancers, then configuring, maintaining, monitoring, supporting, upgrading, patching, backing up and the long list of other technical maintenance tasks were not the best use of our time and expertise. We could do it, but like you, we would need to employ a group of dedicated resources. That just didn’t make commercial or practical sense. Our answer to this problem was managed cloud infrastructure, and after reviewing the main contenders in this space, we opted to work with the following service providers:

Microsoft Azure infrastructure-as-a-service

As a team, we have been building enterprise grade global web applications on Microsoft technologies for over a decade. Typically these applications were hosted in large corporate data centres, so taking a look at Azure was a clear preference, but we also wanted to be sure. So over the last 4 years we have been engineering applications on Azure with a view to learning where it’s limits are and actively watching how Microsoft invest in and develop the services.

We learnt a lot about what works and what wasn’t quite ready for our needs over the years, and earlier this year we decided the time, technology, and services were ready, and we signed up to a Microsoft Azure Enterprise Agreement.

Our investment into the Azure Enterprise Agreement ensures we have the best SLA’s, support, resilience, reliability, and security Microsoft has to offer. Moreover Azure and their underlying data centres have world class security in place and has independently verified ISO 27001 certification from the BSI, along with incorporating controls outlined in the ISO/IEC 27018 standard, which provides a code of practice specifically for processing of personally identifiable information in public cloud services. Azure also has UK G-Cloud “OFFICIAL” accredited infrastructure used by UK government and NHS trusts who hold and transact public sector data. Read more about Microsoft Azure’s policies here.

3scale API management software-as-a-service

API’s are a fundamental aspect of our our technical design philosophy, but we knew that, like managing servers and databases (Azure), managing API keys would be better served by utilising a specialist partner. API key management is the service of issuing secure keys to access pensionsync API’s, along with monitoring and managing access.

As you would expect we went through a thorough appraisal of potential suppliers, and along with reviewing them against our technical requirements, we measured them against our security and reliability needs. Specifically we wanted to be sure that:
  1. HMAC authentication is supported. This prevents the transmission of key secrets during the authentication process.
  2. the pensionsync services could remain accessible even in the unlikely event that our API management provider was inaccessible
  3. No customer data would be transferred to the partner, only authorisation requests
  4. No customer data would leave the the EEA countries as required by the Data Protection Act.

pensionsync’s implementation of 3scale gives us a highly secure, highly available, and highly functional API management platform.

We utilise the top level enterprise grade managed cloud infrastructure from Microsoft Azure.

  • Our data centres are monitored 24hrs for physical security from unauthorised access and environmental threats, and apply strict identity and access management protocols
  • pensionsync has provisioned Azure infrastructure only within Ireland and the Netherlands, meaning no customer data can leave the EU and has been validated by the European Union data protection authorities
  • Our applications hosted in Azure are in ISO 27001:2013 controlled (independently BSI audited) environments. Including ISO 27018 controls relevant to protecting personally identifiable information in public cloud services
  • Azure also has UK G-Cloud “OFFICIAL” accredited infrastructure used by UK government and NHS trusts who hold and transact public sector data
  • Microsoft is committed to executing regular penetration testing of the Azure data centres
  • Private connections to the data centres
  • Encrypted communications (SSL and TLS) during deployments to Azure
  • Multifactor authentication and access monitoring to the production environments.

Our internal data security processes ensure we regularly contact all of our infrastructure service providers to ensure that they are providing our service within the constraints of these points.

It’s worth noting that Microsoft provides better than 99.9% uptime SLA’s across Azure per month. That’s pretty good, but by their own admission it can be improved. We have a planned architectural review session with the Microsoft Azure team in May to take a look at what we’ve done and how it can be improved.

We've architected pensionsync to be highly available and resilient, and this is the reason why pensionsync has two (mirrored) API endpoints. Both endpoints are available 24/7, and in the unlikely event that one is unreachable, you will automatically failover to the other (with no need to take any remedial action within your software application). The endpoints will be physically running in different data centres just in case there is an ‘event’ that takes an entire data centre offline.

In fact, even if our API Management platform used to issue you with your API keys is unavailable, our services will remain available to you as long as you have an active and authorised API key.

In periods of high demand our servers will automatically scale, so that there is no degradation in your service. This is possible because the pensionsync application has been configured to seamlessly load balance and failover when certain thresholds are passed.

Regular maintenance of servers will not result in any pensionsync downtime and your AES-256 encrypted data is temporarily stored in triplicate across 3 separate database servers which automatically handle sharding and rebalancing if required.

Furthermore our partner’s managed data centres are constantly monitored for intrusion detection, DDoS prevention, automatic patching, real-time antivirus protection.

What this means is that we could experience all of the following failures simultaneously and our service would continue to run:
  • 2 of our production databases fail
  • an entire Azure data centre fails
  • and connectivity to our API management platform fails