What we do with study data, in writing.
The practices below are in place today. Each one is something a vendor review can check.
The practices in place
| Practice | How it works |
|---|---|
| A dedicated, covered account for study data | Study leads are received and processed in an Amazon Web Services account used for nothing else, covered by a Business Associate Agreement with AWS. Every AWS service that handles a lead there, from intake and storage to email, keys and logs, is on AWS’s list of HIPAA-eligible services. Meta sends lead notifications straight to that account. Lead alerts go to the study team’s Microsoft 365 mailbox, which Microsoft covers under its data protection terms. |
| Contact details and health answers kept apart | On our pre-screen pages, contact details and pre-screen answers are stored in separate tables, each encrypted with its own key that we manage and AWS rotates. The only link between them is a random reference. |
| AI services opted out of improvement use | Our AWS organization has an AI services opt-out policy that covers every account in it, so AWS does not store or use the content its AI services process for us to improve those services. |
| Participant follow-up from a fixed script | When a study uses our follow-up, texts go only to people who ticked the optional box for automated texts and have not replied STOP. Every pre-screen question sent is the IRB-approved text, word for word, from a stored copy of the approved script, and answers are read by fixed rules. AI only sorts a reply and picks an answer from the approved FAQ; it never writes a question or decides eligibility. Anything off the script goes to a person on the study team. |
| A future-studies list Enrollmentum owns, by opt-in only | The list belongs to Enrollmentum (Illuminare Solutions LLC). We keep it and secure it in our covered AWS account, and we are responsible for it ourselves; that responsibility is not passed to a sponsor, a study site or any other company. A person joins only by ticking an optional box that is never ticked for them. The list is encrypted and holds contact details, a birth month and year rather than an age where the form asks for it, the study they answered, and sex, contact preferences and language only where the form asks, never their pre-screen answers. It is never sold or given to a sponsor, and anyone can leave at any time. |
| Consent recorded, opt-outs checked first | Each lead carries a record of the consent wording the person saw and the time they agreed. Before a lead goes to a sponsor’s or site’s lead service, the system checks the opt-out list; if that check cannot run, nothing is sent. A STOP blocks every earlier consent, and only new consent on a new form counts again. |
| Reports that hold no person | Recruitment reports are built from counts by study, campaign and source. The report data carries no name, contact detail or answer, so producing a report never touches a lead. |
| Two-factor sign-in, one person at a time | Study team members sign in with a second factor. The review site never shows a list of names, phone numbers or emails: a person’s details appear only when a team member opens that one lead, and each opening is logged. |
| Logs without personal data | System logs record codes, counts and random references only, never a name, contact detail or answer. They expire after 30 days. |
| No tracking on pre-screen pages | Pre-screen pages run no advertising or tracking code, and nothing about a lead’s progress is sent back to an ad platform. |
| Set retention and a written erasure procedure | Each copy of a lead has a set retention period. An erasure request follows a written procedure that covers every copy, including the ones removed by hand, and ends with a record of what was removed and where. |
| Changes through tests | Every change to the lead systems is deployed from code after automated tests, with a check after the deploy and a way to roll it back. |
| Credentials in one vault | Passwords and keys live in a password manager, never in code, email or chat. |
The written policies behind them
Written policies cover information security, access control, devices, risk management, change management, backup and restore, data retention and erasure, incident response and breach notification, vendors and business associate agreements, continuity, training, logging, encryption and the use of AI tools. Each maps its controls to the HIPAA Security Rule, the SOC 2 criteria and the ISO 27001 controls it addresses.
A client’s vendor team can ask for the policies, our answers to its security questionnaire and the list of companies that handle study data. Write to hello@enrollmentum.com.
HIPAA, certifications and trial records
The HIPAA Security Rule is the standard our systems are built and run to, and in places they go further than it requires. The rule leaves encryption to each organization’s risk assessment; on our pre-screen pages, contact details and pre-screen answers are each encrypted under their own key. We sign a Business Associate Agreement where a study needs one.
You will not see a claim of HIPAA certification here, because no such government certification exists. The U.S. Department of Health and Human Services says it does not endorse or recognize private HIPAA “certifications”. What counts is the safeguards a vendor runs, and those are listed above.
Enrollmentum does not hold a SOC 2 report or ISO 27001 certificate yet. The policies are already mapped to both, and the remaining records an audit needs are being built.
Our systems handle ads, interest forms and lead delivery, all before a participant consents. They do not create the trial records that 21 CFR Part 11 covers, such as electronic consent, study data capture or electronic signatures. Where a study needs those, they are kept in the sponsor’s or site’s validated system.
How a lead moves and who handles it is on the privacy page.