Case Study: Data Protection & GDPR
About the author...
Paul, and his wife Fiona, used to lead the Vineyard church in Bournemouth, UK. Paul now heads up customer support and training at ChurchSuite. In this article he explores data protection compliance and how ChurchSuite's features can help churches increase their own compliance with the new EU GDPR changes that came into force on 25th May 2018 .
THIS ARTICLE WAS WRITTEN IN 2017, AHEAD OF THE MAY 2018 GDPR LAUNCH DATE. THEREFORE, PLEASE BE AWARE THAT THE SUGGESTIONS AND COMMENTS IN THIS ARTICLE MAY NO LONGER BE RELEVANT, SUFFICIENT OR ACCURATE BASED ON THE SUBSEQUENT LEGISLATION THAT WAS ENACTED.
A question we're often asked by churches is, "How can our use of ChurchSuite help us comply with Data Protection?" It's a great question, and it's especially reassuring to hear churches asking responsible questions and taking privacy and data protection compliance seriously. Of course policies and procedures don't feel particularly "kingdom"; they're often perceived as a distraction from the more important "spiritual" matters like pastoral care and discipleship. I too have known the weight of seeming bureaucracy and red tape during my time in church leadership!
In reality, a data protection compliance breach could be potentially disastrous for a church, with huge reputational and financial consequences. As an organisation in the "people" business, a data protection issue in a church can result in people getting hurt, or even worse if safeguarding is compromised. Since the Information Commissioner's Office don't do routine inspections, the first time you'll likely know if you've got a problem is when there's been a complaint and your policies and procedures come under their scrutiny. The Data Protection Act 1998 (DPA) already imposes significant penalties for data protection compliance failures, non-compliance, and non-disclosure. The new EU General Data Protection Regulation (GDPR) penalties are even higher!
Of course, none of us are legal experts and navigating the path of compliance seems far from straightforward. Hardly a week goes by without a story in the news of a bank or other corporate giant succumbing to a security attack resulting in a data breach. Fraudsters are becoming more and more elaborate in their attacks - brute force penetration attempts at the front door, but also highly sophisticated back door intrusion attempts through phishing scams. For those who don't know what "phishing" is, it's when you get an email purporting to be from someone important, like your bank, inviting you to take some seemingly harmless action like verifying your security details or sharing some personal data in order to confirm your identity. The unsuspecting recipient duly clicks the link in the email and submits the requested verification information, not realising that the email wasn't actually from a legitimate source. Now the fraudsters have all they need to enter by the front door - it's like leaving the key under mat!
It's tempting to think that churches are low risk - after all, who'd be interested in the list of event sign-ups for the mid-week seniors luncheon club run in the church hall? But personal data is incredibly valuable - it's currency, sold on the black market and used for unscrupulous means. Probably most fraudsters are not interested in your church, but they are very interested in the people that might be in your church, and you hold the keys to some of their personal contact details.
At the other end of the spectrum, an inadvertent breach of confidentiality by a well-meaning staff member can also constitute a breach of privacy - that printed report left lying on a staff member's desk picked up by the wrong person, a home address inadvertently given out over the telephone without permission, an email containing sensitive information sent to the wrong recipient by mistake, or worse, sent to the entire church!
As sophisticated as computer and internet security might be - and ChurchSuite has incredibly sophisticated, military grade security protocols and encryption of your data - what do we do about the naive or complacent staff member that saves passwords in their browsers, or leaves their phone or computer unlocked and unattended? This too is like leaving the front door key under the mat!
The UK government has confirmed that Britain's decision to leave the EU will not affect the commencement of the GDPR. In this article I'll focus primarily on data protection and compliance as it relates to a church's use of ChurchSuite, however it's important to remember that both the Data Protection Act 1998 (DPA) and the upcoming General Data Protection Regulation (GDPR) have scope that goes beyond a church's use of ChurchSuite. For example, in the church I used to lead, we had personal information on paper in lever-arch files, in filing cabinets, in documents held on various people's computers and devices - everything from spreadsheets to emails to text messages to social media. Data protection compliance applies to all these areas too!
To set some context, it may be helpful to ask, "whose data is it?" If we believe that the data we hold on our systems belong to us then we are likely going to be resistant to GDPR - someone (the EU!) wants to mess with our toys! On the other hand, if we are 100% clear that each person's personal data belongs to that individual alone, and that we are custodians of their data, then we'll likely have a much healthier (and dare I say, gracious) response to GDPR. When we see ourselves as custodians, charged with a "trust" (just like if we were trusted to look after someone else's child), we'll likely want to do our very best when we receive, store and process people's personal data. I suspect we'll also be more ruthless about removing any data that we don't wish to hold within that trust.
Just to say too, that as much as Data Protection compliance is important to you (we hope!), it's one of our highest priorities at ChurchSuite. We have our own policies and procedures that govern data security and the data held on our servers on your behalf. We have strict policies around data access i.e. in order to provide customer support to a question you're asking, and when troubleshooting issues or bugs. All access to your account, whether by your own users or by the ChurchSuite team, if "Support Access" is enabled, is logged and audit-able.
ChurchSuite also has elaborate monitoring systems to watch the health and security of each church's account - for example, too many failed log in attempts and the IP address is blocked - we'll know about it first!
At a more practical level, we're ultimately committed to providing churches with a useful ministry tool that enables the kingdom; so we're constantly developing new features and functionality to meet the changing needs of churches, including functionality that lends itself to data protection best practice and compliance. Indeed the new GDPR has prompted us to re-assess all of ChurchSuite's systems and, where appropriate, to introduce new features to help churches in their own compliance. We'll cover some of ChurchSuite's "helps" throughout this case study.
So let's begin...
Taking stock #1...
Thinking about each of the ChurchSuite modules in your admin-facing system that your church uses,
- Identify and list all the ways your church adds personal data into each module, including contact details, attendance or tracking data, and notes.
- Note any additional processing of information you carry out in your admin workflows within each module, such as communications you send, notifications to others in your church that get triggered, and any reports you produce and distribute in those workflows.
- Are there any areas of "bad practice" or risk that needs addressing? For example, "cribbing" profile images from people's social media profiles without consent(!!!), or recording Notes that express opinion rather than fact, or where consent has not been obtained.
Is GDPR relevant to my Church?
The simple answer is 'yes'. The GDPR applies to both ‘controllers’ and ‘processors’ of data. The definitions are broadly the same as under the DPA – the controller (the church) says how and why personal or sensitive data is processed, and a processor (ChurchSuite) acts on the controller's behalf to carry out processing within the controller's purposes.
Processors in the context of your use of ChurchSuite will include third parties like your external book keeper who may carry out certain admin tasks on behalf of your church.
Taking stock #2...
Continuing with the data mapping audit you started earlier,
- Does your collection and use of personal or sensitive data fall within the "purposes" of your current Data Protection policy? Are there current uses that fall outside the current scope?
- Are your policy's stated "purposes" sufficiently broad enough to cover all your ministry and activity? Highlight any areas that need further expansion in your policy.
- Note down any third party "processors" that use or further process the personal data in your ChurchSuite account e.g. a Book keeper, ChurchSuite integrations such as MailChimp, Planning Center, Stripe, GoCardless, Textlocal. To what extent are those third parties sufficiently aware of your Data Protection policy and do their workflows and practices comply with your policy and the GDPR?
What data is covered by GDPR?
Like the DPA, the GDPR applies primarily to ‘personal data’, but it also governs the processing of 'sensitive data', which ordinarily is restricted, but is permitted by religious organisations.
The GDPR’s definitions are much more detailed - much has changed since 1998 in terms of the type of data churches hold, the uses of data, and the methods of storage and transmission. For example, GDPR suggests that even information such as an online identifier like an IP address can now be considered personal data. As you may know, your admin-facing ChurchSuite system logs the IP address of users when they access ChurchSuite and My ChurchSuite - this is part of our security reporting so that you can identify logins from unrecognised IP addresses or devices.
What is the legal basis for processing personal data?
A key feature of GDPR is that churches must have a lawful basis for processing (which includes storing) personal information, and if challenged, be able to justify that basis. Of all the legal bases provided for by GDPR, most churches will rely on the "consent" of the data subject. Additionally, in regards to 'sensitive' data, Article 9 Para 1 says that, "Processing of personal data revealing... [among other things] religious beliefs... is ordinarily prohibited", however, under an exclusion provided in Article 9 Para 2(d), churches (not for profit bodies with a religious aim) are permitted to process sensitive data when it is carried out in the course of its legitimate interests with appropriate safeguards and on condition that the processing relates solely to...
- the members or to former members of the church,
- or to persons who have regular contact with it in connection with its purposes,
- ...and that the personal data is not disclosed outside that body without the consent of the data subjects.
This may be good news for some churches. As an alternative to consent, there may be a compelling case for legitimate interest. For example, for maintaining an official membership or electoral roll, and maintaining group lists and rotas. However, if you do plan to further process data beyond legitimate interests, you will likely need another legal basis for processing for that purpose - most likely the explicit, opted-in consent of the data subject.
Under the GDPR there are six legal basis for processing. No one basis is better than any other. Consent is only appropriate if you can offer people real choice and control over how you will use their data, and want to build their trust and engagement. But if you cannot offer a genuine choice, consent is not appropriate. If you would still process the personal data without consent (e.g. because you have a legitimate interest basis), asking for consent is misleading and inherently unfair, and therefore not compliant with the GDPR.
Ultimately it's for the Data Controller to choose the most appropriate basis/bases for each of their purposes. Therefore "consent" may not be appropriate in every case. For example, you wouldn't likely need to obtain "consent" to share the names of individuals on the Coffee rota or Worship rota with other church members. In this instance, the information is shared with others "in order to carry out a service to other church members" and so this will likely qualify as a reasonable legitimate interest. Of course, if you intended to communicate about church events to rota members, this non-rota-related processing may not be considered "legitimate interest" (unless the events were rota team or training-related), in which case you might need another basis.
Where churches are processing personal data for children, and where consent is your lawful basis for processing, the GDPR, only children aged 13 or over are able provide their own consent. For children under this age you need to get consent from whoever holds parental responsibility for the child. Where churches offer services for children, e.g. free/pay events open to sign-up by children, your privacy notice should be especially written in a clear, plain way that a child will understand.
The key GDPR principles
At the heart of the GDPR are seven key principles - that personal data shall be...
- processed lawfully, fairly and in a transparent manner in relation to individuals;
- collected for specified, explicit and legitimate purposes and not further processed in a manner that's incompatible with those purposes; further processing for archiving purposes in the public interest or historical research or statistical purposes shall not be considered to be incompatible with the initial purposes;
- adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed;
- accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that's inaccurate, having regard to the purposes for which they are processed, is erased or rectified without delay;
- kept in a form that permits identification of data subjects for no longer than is necessary for the purposes for which the personal data is processed; personal data may be stored for longer periods insofar as the personal data will be processed solely for archiving purposes in the public interest, historical research or statistical purposes subject to implementation of the appropriate measures required by the GDPR in order to safeguard the rights and freedoms of individuals (more on this later);
- processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures (this also covers secure access to data).
- the subject of accountability - i.e. the controller shall be responsible for, and be able to demonstrate, compliance with the principles (this is a brand new principle)
Let's explore each of these principles in more detail in the context of your church's use of ChurchSuite...
1. Lawfulness, fairness and transparency
Churches should provide people with information about his/her personal data processing in a concise, transparent and intelligible manner, which is easily accessible, distinct from other undertakings between the church and the person, using clear and plain language.
Transparency is achieved by keeping the individual informed and this should be done before data is collected and where any subsequent changes are made. It's important to remember that some data isn't always collected directly from individuals, but may be derived from other sources, or observed by tracking. For example, small group attendance and event attendance record keeping would fall under this definition, so churches should make it clear to people that this 'observed' tracking is being recorded about them. The GDPR has a mandatory list of the information that should be given to individuals where data is obtained directly from them, but also where it is obtained indirectly. How you let individuals know about what you are doing will depend both on your methods of communication and on your target audience.
Taking stock #3...
- For each area where you collect or process personal data about people in your ChurchSuite account, how are people made aware of your data protection policy, and the extent of the information you maintain and the purposes that information is held?
- How are you complying with an individual's right to be informed and kept up to date, both at the point of initial collection of their personal details, but also information that is subsequently added by other "observed" sources?
- Considering the ICO's new Code of Practice, does your privacy notice need to be updated, and are there steps in your processes where that privacy notice could be more clearly and transparently communicated? For example, everywhere that you solicit information from people, is your privacy notice clearly communicated?
2. Collected for specified, explicit and legitimate purposes
Processing personal data is only permissible if and to the extent that it's compliant with the original purpose for which data was collected. Processing “for another purpose” later on requires further consent.
For example, someone outside your database who signs up for your Alpha Course should not subsequently find themselves being added to your Address Book and end up on your mailing list, or the recipient of follow up event promotions, without their prior agreement. The only exception to this requirement is where that “other purpose” is “compatible” with the original purpose and is clearly communicated at the point of signing up.
Obviously this is open to interpretation, so your church should be able to demonstrate a clear link between the "original purpose" and any subsequent "other purpose". Our suggestion would be to be as clear as possible about possible other purposes at the point someone is signing up for your Alpha Course, and seek consent at the time people are submitting their details (with a genuine default choice to opt in, not out, of those other purposes) - one way to achieve could be through the use of the custom questions that you can add to event sign-up.
Taking stock #4...
There are occasions where people will enter your ChurchSuite database but are not added directly to the Address Book or Children module - one is event sign-up in the Calendar module, where people outside of your database may be signing up for your public-facing events, another is child visitors (and their parent/guardians) added through the Child Check-in system. Visitors are retained on the check-in system as visitors for a defined retention period (set in your Children module settings), and are automatically deleted if they don't check-in for the duration of the retention period. What about givers who donate to your church but are not part of your church - their details may be stored in your Giving module.
- Where consent if your lawful basis for processing, do your workflows include obtaining appropriate consent from individuals who sign-up to your events before adding them to your Address Book? How is that consent noted?
- Where consent if your lawful basis for processing, when following up with families of visiting children who indicate they're going to be attending regularly, do you seek appropriate consent before adding the children to your Children module and/or parents to the Address Book? How is that consent noted?
- When children in your Children module reach the age of 18, previously they were under their parent's data protection consent. How do you obtain permission from the now adult child before moving them from the Children module to the Address Book? How is that permission noted?
- Certain contact information from givers is legitimately needed for the purposes of UK Gift Aid reclaims, and must be held on record for up to six years and you must be able to demonstrate a clear link between the giver, the declaration and the donation. You likely have a legal obligation lawful basis for processing. Does your data protection policy and privacy notice sufficiently communicate this?
3. Adequate, relevant and limited to what is necessary
This principle suggests that churches should ensure that only personal data that is necessary for the church's specific purposes is processed. This principle is all about the amount of personal data collected, the extent of processing, the period of retention and accessibility.
Churches need to make sure that they collect enough data to achieve their purposes, but not more than is needed. If you don't need to know people's employer, job title, former name, or work telephone number then probably best to not record that information unless people choose to add that information voluntarily, perhaps through My ChurchSuite.
Taking stock #5...
1. Are you using My ChurchSuite, the member-facing platform? For those in your church who do have login access to My ChurchSuite, this is a great way of empowering individuals to take personal responsibility for maintaining their own information. My ChurchSuite could therefore be a significant step towards greater GDPR compliance in your church, as people can have real choice about the extent of personal information they choose to share with your church (as long as you allow the fields to be editable!). Importantly, they can manage their own privacy settings and communication preferences, giving them choice over what contact details are shared with other church members within My ChurchSuite e.g. fellow rota members, fellow small group members etc, and what communication methods they are happy to receive from you.
2. Review the standard, optional and custom fields in use in your Address Book and Children module (in the module settings). Does your use of these fields of data fall sufficiently within the "purposes" stated in your Data Protection policy? For example, a custom field for membership status will probably fit neatly within your policy "purposes", but what about any custom fields you've created for more sensitive information like internal safeguarding fields or pastoral flags etc, which people may not be aware you're maintaining.
4. Accurate and kept up to date
Personal data must be accurate and kept up to date – this will be familiar from the EU Data Protection Directive out of which the Data Protection Act was written, and which will be replaced by the GDPR. The basic rule of thumb is that inaccurate or outdated data should be deleted or corrected. This principle should be a significant priority for churches as data controllers; to take, as the Act says, "every reasonable step" to comply.
Taking stock #6...
Clearly the most effective way to comply with this GDPR principle is by enabling people to maintain it themselves - something they can easily do through My ChurchSuite.
Be mindful of those who may, for whatever reason, be unable to, or do not wish to, use My ChurchSuite. Instead, consider other ways you can help those people help you maintain their details. For example, you could create a Smart Tag that matches all contacts or children that do not have My ChurchSuite login and then filter the Full Details report in the Address Book and Children module reports against that tag. You could then periodically provide that report to those individuals and ask them to give it back to you with any changes they have made.
A further suggestion is to make use of the My Details platform within ChurchSuite Connect, which can be run at your Information Desk at weekend services using a laptop or tablet. "My Details" includes an optional "Edit" mode that can be used to enable existing contacts to review and update their personal details in a safe and secure way.
How does your church facilitate all people being able to review and update their personal information held on your ChurchSuite database? What workflows do you have for ensuring data added to your Address Book, Children and Giving modules is being kept up to date? When was this last done?
5. Kept for no longer than is necessary
The DPA and GDPR state that once you no longer need personal data for the purpose for which it was originally collected, you should delete it unless you have other grounds for retaining it. This means there should be a regular review process in place with methodical cleansing of your Address Book, Children module and Giving modules. In my experience church leaders are 'hoarders'! They like to keep people on the system indefinitely, long after they've left the church - often for not very persuasive reasons.
There are a number of ways you might identify inactive contacts in your database. Using Smart Tags you may be able to create a set of conditions to match people who fall below a certain level of engagement - for example, to identify those "not in a small group, not serving, not giving, do/don't have certain key dates, custom fields or tags, not logged in to My ChurchSuite for a certain time". Are these candidates for archiving or even deleting?
Obviously data informs decisions, data doesn't determine decisions, so you should use the results carefully and consider how reliable the underlying data is that's generating your smart tag results. In the first instance you may wish to reach out to resulting people to establish where they are at and then decide whether they should be archived or deleted.
A discipling church will already be good at using their ChurchSuite data to monitor engagement levels - as a pastor I was keen to move people on in discipleship. But equally important are those becoming disengaged and slipping out of fellowship. We'll want to pursue them to an extent, but is there an appropriate time where we have to accept that they've gone, and archive or delete their personal data?
One suggestion is to look at your children group attendance - a great indicator of whether families are still attending, or whether they're slipping out of community. Changes in small group attendance, serving patterns or giving patterns, event signup and event check-in attendance data can also be used to provide helpful insights into people's engagement.
Taking stock #7...
6. Appropriate security of the personal data
Personal data must be protected against unauthorised access using appropriate organisational and technical measures. This goes to the heart of protecting the privacy of individuals. Data controllers and processors need to assess risk, implement appropriate security for the data concerned and, crucially, check on a regular basis that it is up to date and working effectively.
We do encourage you to familiarise yourself with ChurchSuite's security protocols. Of course no system can ever promise to be 100% secure, as I said at the start of this article. However, with your data encrypted at rest and during transmission, the risk of personal data being compromised is highly unlikely. But what about your church's internal security measures? In my experience, internal weaknesses are the greatest area of risk, especially with so many potential users and the turnover of volunteers/users. And let's be honest, not everyone is a computer geek like me(!) - most people probably have little understanding of computer security.
Taking stock #8...
- Are users required to periodically change their passwords? The latest security advice actually suggests passwords should not be changed too frequently! Your Administrator area within ChurchSuite will tell you when each user last changed their password.
- Do you permit passwords to be saved in a user's browser (this is a significant risk with most browsers and should be discouraged as bad practice)?
- Do you employ a minimum password strength?
- Do your users have permissions for only the functionality they need to do their role? Reducing access (without restricting their ability to perform their role) will reduce risk.
- What controls are in place for data that is exported or reported out of ChurchSuite, so that data remains secure once exported/printed? Do you know what happens with all those pieces of paper?
- Have users had sufficient training to use ChurchSuite in accordance with your policies and purposes? Do you have an IT policy that covers online and computer security?
- How are your security procedures monitored and enforced?
- What are the weakest aspects of your security procedures and how could these be strengthened to ensure compliance with this principle?
The final principle under the GDPR states that data controllers must be able to demonstrate compliance with the other principles.
This is a brand new requirement and is basically about being accountable. It's not enough to comply, you have to be seen to be complying and be able to demonstrate it under scrutiny. The range of processes that churches have in place to demonstrate compliance will vary from church to church, but may include:
- assessing current practice and developing a data privacy governance structure, which may include appointing a designated Data Protection Officer whose role includes regular data audits and enforcement of policies and procedures appropriate to your church;
- creating a personal data inventory - some of your question responses from this article are about 'taking inventory';
- implementing, updating and communicating your privacy notice at every opportunity (see later);
- obtaining appropriate consent(s) and documenting/logging at every opportunity;
- using appropriate organisational and technical measures to ensure compliance with the data protection principles;
- using Privacy Impact Assessments (not covered in this case study, but referenced in the ICO website guidance);
- creating a breach reporting mechanism and communicating that clearly in your church's data protection policy, and
- educating and training your users so that they have the right knowledge and information.
Taking stock #9...
New rights for individuals
The GDPR establishes some important new rights for individuals (data subjects) and strengthens some of the existing rights that currently exist under the DPA. The GDPR now provides the following rights for individuals:
- The right to be informed - The right to be informed encompasses your church's obligation to provide ‘fair processing information’, typically through a Privacy Notice. It emphasises the need for transparency over how you use people's personal data.
- The right of access - You must provide, on request, a copy of the personal information you hold free of charge. The removal of the £10 subject access fee is a significant change from the existing rules under the DPA. You also have less time to comply with a subject access request under the GDPR. Information must be provided without delay and at the latest within one month of receipt of a request.
- The right to rectification - Individuals are entitled to have personal data rectified if it is inaccurate or incomplete.
- The right to erasure - The right to erasure is also known as ‘the right to be forgotten’. The broad principle underpinning this right is to enable an individual to request the entire deletion or removal of all personal data where there is no compelling reason for its continued processing. The right to erasure does not provide an absolute ‘right to be forgotten’, but individuals have a right to have personal data erased and to prevent processing in specific circumstances:
- Where the personal data is no longer necessary in relation to the purpose for which it was originally collected/processed.
- When the individual withdraws consent.
- When the individual objects to the processing and there is no overriding legitimate interest for continuing the processing.
- The right to restrict processing - Under the DPA, individuals have a right to ‘block’ or suppress processing of personal data. The restriction of processing under the GDPR is similar. When processing is restricted, you are permitted to store the personal data, but not further process it. You can retain just enough information about the individual to ensure that the restriction is respected in future.
- The right to data portability - The right to data portability allows individuals to obtain and reuse their personal data for their own purposes across different online services. It allows them to move, copy or transfer personal data easily from one IT environment to another in a safe and secure way, without hindrance to usability. To fulfil this, you must be able to provide their personal data in a structured, commonly used open format or machine readable form. "Open formats" include CSV files. "Machine readable" means that the information is structured so that software can extract specific elements of the data, thereby enabling other organisations to use the data.
- The right to object - Individuals have the right to object to direct marketing (including profiling) and processing for purposes of historical research and statistics. The GDPR defines "profiling" as any form of automated processing intended to evaluate certain personal aspects of an individual, in particular to analyse or predict their economic situation, health, personal preferences, reliability, behaviour, location or movements. You may wish to review your use of Smart Tags, which some churches may use for profiling purposes - a good question to ask is "how would you feel if your knew you were in that smart tag?"
- Rights in relation to automated decision making and profiling - The GDPR provides safeguards for individuals against the risk that a potentially damaging decision is taken without human intervention. These rights work in a similar way to existing rights under the DPA. You should identify whether any of your church's processing operations constitute automated decision making and consider whether you need to update your procedures to deal with the requirements of the GDPR. A Smart Tag does not in itself constitute automated profiling, but a Smart Tag may be used in a way to make decisions or determinations about someone based on the presence or absence of matching criteria.
Taking stock #10...
The GDPR uses the term ‘Privacy Notice’ to describe all the privacy information that you make available to individuals when you collect information about them. The Information Commissioner's Office (ICO) have produced a helpful document about the Code.
Essentially, if consent is your lawful basis for processing, you need to consider how you will gain and record individuals’ consent, if required. There's a fundamental difference between telling a person how you’re going to use their personal information and getting their consent. If your consent mechanism consists solely of an “I agree” box with no supporting information then users are unlikely to be fully informed and the consent will not be considered valid.
When relying on consent, your method of obtaining it should be displayed clearly and prominently, and ask individuals to positively opt-in. In addition if you are processing information for a range of purposes you should explain the different ways you will use their information, and provide a clear and simple way for them to indicate they agree to different types of processing. In other words, people should not be forced to agree to several types of processing just because your privacy notice only includes an option to agree or disagree to everything! People may wish to consent to their information being used for one purpose but not another.
A good example is providing an event sign-up question where people can select to opt in to being added to your Address Book. Best compliance would be that they are treated as opted out as the default, and that they are invited to opt in as a choice. It may also be helpful to get in the habit of using language such as, "by submitting your details in this online form, you consent to... If you do not wish this... do not submit your details" on public-facing forms such as event sign-up, newcomer connect, online giving etc.
If you're relying on "legitimate interest" as your lawful basis, you should still communicate your privacy notice to those already in your database, and arguably, let them know what information they do have so that this can be reviewed and updated. In this scenario though, having stated your basis is legitimate interest, you should confuse the data subject by asking for their consent to your privacy notice or the data you hold.
How can ChurchSuite help towards compliance with the GDPR?
The following recommended resources can provide further help with Data Protection and GDPR:
- The ICO (Information Commissioner's Office) website. They also have a GDPR reform section, that has comprehensive coverage of GDPR with regular updates as each consultation takes place.
- Your local UCAN Administrator's network.
- The Evangelical Alliance.
- Legal/professional advice from a Data Protection and/or charity expert - you may have people in your church who can help, or you may need to instruct someone professionally to advise your church. There are some great charity/governance consultants out there that will provide guidance to trustees and church teams.
- Overseers or the governing body for your church's affiliation, denomination or stream.
- Other churches in your local area or network.
In addition, between now and the introduction of GDPR, we're committed to developing additional functionality to help you towards greater compliance in your use of ChurchSuite. Obviously we're not responsible for your church's compliance (sorry!), but we can give you additional tools and workflows to assist you with compliance and consent. Check out the related "ChurchSuite and GDPR" article for the latest updates.
We hope the above commentary is helpful as you evaluate your church's compliance with the GDPR. We'll add to and update this case study as new information becomes known. But if you have any questions or suggestions, as always, please do get in touch with the ChurchSuite support team and we'll do our best to help. Email firstname.lastname@example.org