Chapter 8: Clinic IT and Data Infrastructure
Data security is important for any organization that collects, retains, or otherwise comes into contact with identifying information such as individuals names, phone numbers, and email or physical addresses, particularly if those individuals are at a higher risk of danger or harm than the general population, such as survivors of intimate partner violence.
At a technology abuse clinic, data security is especially important. In addition to the safety and well-being of clients, the legitimacy of the clinic itself is at risk if the clinic cannot safeguard its own data. In this chapter, we discuss privacy-preserving practices for clients, data retention policies, communications infrastructure, and analyzing clinic data for service improvement.
These practices are important for the safety of clients, staff, and the clinic itself.
In this chapter:
Collecting Personal Identifiable Information (PII)
Information that can be used to identify an individual either directly or indirectly is known as Personal Identifiable Information (PII). According to the United States’ Department of Labor, this includes:
names, birthdays, social security numbers or other ID numbers
physical addresses, telephone numbers, or email addresses
online contact information, including social media handles
combinations of demographic information such as gender, race, age, and geographic descriptors.
This information can be stored on paper, electronically, or both. Technology abuse clinics may encounter some subset of this information while working with clients. Safeguarding PII is crucial, as failure to do so can result in substantial harm to clients.
Data minimization is the principle of collecting only the information that is relevant and necessary to provide a service. Which data meets the criteria of relevance and necessity will vary depending on the clinic's service delivery model. In some models, there may be no need to collect any PII from a survivor other than what is shared during a consultative session. In other models, it may be necessary to gather names, pronouns, and contact information. In early stages of a clinic, it may be beneficial to select a service delivery model that requires collecting zero information from potential clients, as was the case for all three existing clinics when they first started operating.
Minimal data that may be considered relevant and necessary for providing service at a technology abuse clinic, especially during intake, might include:
technology concerns (description of concerns, types of devices used)
a name for the client (which may be a pseudonym)
contact information (phone, email) for the client and/or their DV advocate
limited demographic information, including languages spoken by client
Legal risks of data collection
Collecting PII may also present legal risks, depending on the laws governing your clinic. For example, a client (or abuser) may be able to file a subpoena asking for data from a client appointment. Some advocacy organizations are legally shielded from subpoena, and some are not; this depends on local and state law.
A common practice among organizations that are not protected from subpoenas is to use a combination of tactics, such as not collecting identifiable information, minimizing the usefulness or specificity of any data retained, and proactively deleting any collected data. This will shape the policies of how the clinic runs, including how consultants are trained to treat note-taking, which often includes a wealth of client information.
It is useful to consult with legal experts to assess liability and risk when developing internal practices surrounding data collection discussed in the following sections.
Redacting data collected from client sessions
Technology consultants will need to take notes during appointments, either with pen and paper, or electronically. If the clinic does not keep notes from sessions, then consultants and the clinic are responsible for properly disposing of those notes. However, the clinic may choose to retain notes from sessions for various reasons.
Clients may sometimes share sensitive information during an appointment, even if not directly solicited. If the clinic retains session notes, they should incorporate a practice for anonymizing notes and not retaining sensitive information, either by not storing it or redacting it. Some examples of data that should not be stored in a client file are:
home addresses, specific geographic location, social security numbers, ID cards
clients may want to share this information so consultants can determine if the client is, for example, 'searchable' online or vulnerable to identity theft
log-in information, including passwords or pins
documentation or evidence of abuse, such as screenshots of log-in history or data requests from technology platforms
client's personal photos, especially in cases of image-based abuse
In all of these cases, an alternative to the clinic retaining the client’s information is for the technology consultant to guide clients on how to navigate the steps or interfaces themselves, on a safe device that is preferably owned by the client.
Technology consultants may require communication infrastructure, especially if the clinic offers remote appointments. This includes video conferencing software (like Zoom, Skype, or Google Meet), an email address, or a phone number to use for client communication. For both the client and the consultant's safety, it is important that all accounts used by consultants to communicate with clients are not personal accounts. Not only does this protect the identity of consultants, it prevents client PII from being mixed into the personal accounts of consultants.
Other clinic infrastructure that does not deal directly with client PII may be connected to consultants’ personal accounts. Examples of this include messaging platforms, such as an instant messaging platform (e.g., Slack, Discord, IRC) or a mailing list to communicate with other consultants during and between sessions.
When planning communications infrastructure for technology consultants, some important considerations include:
What client information is included in the application? (e.g.: will the client’s phone number or email address be retained by the application?
If so, what is the access and retention policy for this information?
How will you communicate this policy to technology consultants?
Is the application traceable or connected to the technology consultant's personal information?
Technology consultants should avoid using personal phone numbers or personal emails for both their own and the client's safety.
What safeguards will the clinic put in place to ensure that the communications infrastructure is being used in accordance with the data safety protocols developed by the clinic?
Storage, access, and authentication
Regardless of the client data that is collected, the clinic should maintain a policy for how that data is stored, by whom and how it can be accessed, and for how long the data will be retained.
Data should be stored in a secure location, whether physical or virtual. When selecting a virtual storage platform, considerations may include:
What are the data storage policies of the storage platform? Does the storage platform have a policy of reading or selling data uploaded by their users? This is particularly common on free-tier services; some platforms may have a commercial licensing option that restricts sale of user data.
What are the data storage access control policies? Can you set permissions for individual files, users, or revoke permissions easily?
Does the data storage platform require 2-Factor Authentication for workspace members to access data?
Encrypted storage is nice-to-have, but not necessary for clinic safety.
Most security problems relate to access control (who has access to what) and authentication (identifying who is making an access). While we discuss this in the next paragraph, it is important to keep in mind what capabilities your chosen storage platform has to support controlled access and authentication.
Access and Authentication
Data access refers to whom within the clinic has access to individual pieces of data and authentication refers to how the system identifies who is attempting to gain access.
Granting access to sensitive data should be managed with clear, transparent policies and accurate record-keeping. Each individual requesting access to each piece of sensitive data should have a clear, defensible reason for needing to access that data, and a record of who has requested and been approved access should be kept as long as the data lives. Access should also be revoked at key points, such a when a technology consultant or staff members is no longer working at the clinic.
In general, the more people who have access to a single file, the greater the likelihood that the file is compromised. To decrease the likelihood of compromise, best practice entails restricting access to data as much as possible. This also pertains to the granularity of data; an individual requesting data for a particular client should only be able to see the data for that particular client, not all client data.
Equally as important, the clinic should maintain strong authentication practices. This generally means enforcing strong passwords that are stored in secure location such as a password manager (not a sticky note on a laptop or in a plain-text document!) and mandatory 2-Factor Authentication.
Managing Data Policies
Clinics should have clear policies that limit the duration of time that data is retained and when access to existing data is revoked. Deletion of data can be triggered by an event, such as a client concluding services with the clinic or a technology consultant deciding to leave the clinic. In these examples, a designated staff number may want to delete all data associated with that client (notes, screenshots, text messages, or emails), or revoke all access permissions granted to the technology consultant. Data deletion may also be triggered by a designated time period (e.g. deleting all data from inactive clients on every 90 days).
For each type of data about a client that the clinic collects, it is useful to write down why it is collected, who has access to it, and how long or under what circumstances it should be retained. On a regularly scheduled basis (e.g. the first of every month, or every 90 days), someone in the clinic may want to review all actively held data, revoke or reset any permissions, and purge any data that should not be kept. Depending on how the clinic is structured, these policies may need to be developed in conjunction with the policies of any agency partners. The National Network to End Domestic Violence has resources with additional guidance on managing data and records.
Research, Evaluation and Analytics
The clinic may want to collect and retain some information for evaluating their services, internal analytics, and general research. For example, a clinic may be interested in collecting certain pieces of demographic data to determine whether they are under-serving a particular community, what barriers to service clients are experiencing, or whether the clinic should invest more resources in responding to a specific technology issue that shows up disproportionately.
Data that is gathered for internal evaluation and research typically does not require approval from an Institutional Review Board, even if the clinic is affiliated with a university, unless the clinic intends to publish or share data externally (e.g., presentations, journal or conference papers, or peer-reviewed articles). If your organization has interest in publicly releasing its data for research or other purposes, you will need to determine whether that work requires human subjects approval from an Institutional Review Board before you collect that data. When sharing data externally, be mindful that in addition to explicit personal identifiable information, such as names and addresses, client stories that are highly specific can function as identifying.
Data can be gathered passively during the service provision itself, such as by collecting or preserving notes, or recording a call. Alternatively, data can be solicited for the express purpose of evaluation, such as asking clients to fill out and pre-and-post surveys about their experience with the service and what they've learned. In the latter case, such data should not be required for or otherwise interfere with service, and this should be made clear to clients. In either case, it is important to inform clients of what data is being collected and with whom it might be shared.