With GDPR coming into effect this week, we feel that now is as good a time as any to provide you with a detailed overview of how CMAP's technical development, infrastructure & processes ensure our clients have peace of mind knowing that:
A) By using CMAP, your organisation will not be in breach of GDPR.
B) CMAP is GDPR compliant and has infrastructure in place to protect your data
This update will also cover:
- The changes we've made to the CMAP application in preparation for GDPR
- How the technical infrastructure we have in place supports GDPR compliance
- How our internal processes support all of the above
Privacy by Design
At CMAP, we're fortunate enough to have a team of engineers & QA Experts who are truly nailed on, so we've taken a Privacy by Design approach to development for years.
This means that data security & privacy is considered during the design & build stage, before new functionality can be released.
This is important, because we identify potential issues at an early stage, usually before a feature is launched to our users, so we can address them straight away.
The CMAP Product & GDPR
Here's how CMAP functionality facilitates compliance with the key fundamentals of GDPR:
1. Right to Access
Under GDPR, an individual has the right to access their data records; so all of the data your organisation holds on that individual needs to be available to them at their request.
CMAP Users with the correct administrative user permissions within their organisation have the ability to exercise Data Access Requests via CMAP. There are a number of ways this can be managed, either through:
- Excel exports
- Direct Reporting Service - our ODBC tool
- Grids in CMAP enable you to create custom data views so you can easily surface specific data sets when required
2. Right to be Forgotten
Deleting a contact in CMAP used to archive their data so that the associated project information could be retained.
Now, we've introduced a permanent delete option, where a contact can permanently be removed from your version of CMAP.
This removes the contact from any associated projects.
Though there is also the option to to anonymise the contact record, so you can keep the link between the contact & any associated project data, but removing access to their personal data.
3. Data Retention
To help you manage your data retention policy, we've added Date Created & Date Modified fields to each contact record page.
With this information, you can easily run reports in CMAP to filter contacts by those reaching their maximum retention time, so you can simply remove them from CMAP at the appropriate time.
4. Right to Process - Consent
We've added the ability to mark-up any of your contacts as Do Not Contact so that you're aware which of your contacts don't want to be marketed to by your business.
Sometimes your reasons for processing an individual's personal data can vary. If this is the case in your organisation, you can easily set up a custom contact field to record your legal reason for processing their data - for example, legitimate interest.
5. Data Portability
In CMAP, we facilitate this in a number of ways:
- Grids - enable you to apply custom filters to your contacts database to better-manage your data
- DRS - our ODBC tool enables you to extract your raw data from CMAP however you like
- API - access to our API is available to all CMAP users, but this is down to you as a business to action its use
System Infrastructure & Security
CMAP is cloud-based software hosted on Microsoft's Azure network, which we've been a part of since 2013.
This means we already have a range of security protocol in place to keep your data safe, including:
- All data inputted into CMAP is securely encrypted via SSL RSA 2048 bit encryption in transit and again at rest in both the Azure SQL databases & document storage
- User passwords are also hashed and encrypted within the database, so they're not visible to CMAP staff
- We also retain data backups for 30 days, which enable us to restore databases to any point in time during that period - even to the exact second - in the case of disaster recovery
Our Internal Processes
At the beginning of this article, we talked about the idea of Privacy by Design. Here's how our internal processes come together to put the idea of privacy by design in to practice:
Agile Development Sprints
Our product development teams use fully agile development methodologies based on SCRUM principles.
In simple terms, that means that CMAP is developed in 2 week cycles or 'Sprints'.
The 1st day of each 2 week Sprint is solely dedicated to planning.
Our main goal is making CMAP - and all the functionality that goes into it - easy to use.
So it's absolutely essential that our Sprints are a combined effort between our product, support QA & Development teams.
Therefore, half of our planning time is spent listening to feedback & QA from our users, which is fed-back to us via our Support, Onboarding & Product teams.
Here, we can identify the key issues that need solving as soon as possible.
Once we've collected feedback from our users, the rest of the day is dedicated to technical planning; ensuring we can carry-out the appropriate upgrades & deliver them on time.
We then reconvene to ensure the solutions our engineers come up with work from a user experience perspective via a combination of daily cross-departmental meetings, as well as daily code reviews.
Our QA Process
Our dedicated QA team rigorously test CMAP's functionality via a multi-tier QA process, which includes:
o Automation testing
o Regression testing
o Manual testing
o User acceptance testing
o Alpha/Beta testing where deemed necessary
As well as this, all CMAP source code is held within GitHub repositories, which provide full auditing capabilities, as well as the ability to roll back to previous releases.
We also have full version controls which enable us to push out system releases and hotfixes in a controlled manner.
Restricted data access
Access to sensitive data is restricted only to employees who require access to fulfil their daily duties.
As such, our internal systems have been chosen to ensure they provide the appropriate levels of security and auditing, based on the nature of the data held within them.
Access to client data is therefore restricted based on the following roles:
o Access to initially import data sheets
o Access to live / test versions of CMAP for configuration and import checking
o Access to live / test versions to assist with issues raised by end users. This is so that support staff can view the exact issue a user is experiencing, which is sometimes related to the data itself
Tech Team - Development & QA
o Require access to live / test versions of CMAP to resolve issues escalated by the support team. Also used to test changes to the system in order to ensure existing client data isn’t compromised.
o Access to backup data to in order to restore data if required
o Access to raw databases to assist with data exports & maintain the performance of the database. We also carry out bulk data manipulation upon the request of clients.
Hopefully, we've covered everything you need to know from a technical perspective about CMAP & GDPR in this post. If you would like to know more, you can read a brief introduction to CMAP & GDPR here.
If you have any questions related to this topic, feel free to get in touch with us via the Contact Us page.