Security and participant data

• When a study asks for it, the server reads answers as they arrive, to score a questionnaire, raise an alert the researcher set up, decide which part of the study comes next, or file a person who signs up in the study's panel. It may also read that participant's earlier answers from the same sitting, and it stores only the score, alert, next step or panel entry that results.

  Confidential studies

• A Confidential study's answers never appear in Sigmer's logs.

  Confidential studies

• An operator of Sigmer with access to its database and its key service can open a Confidential study's responses. What stands against that is who holds that access, not cryptography: a read through Sigmer's own software is recorded in the workspace's audit log, but one made directly in the database would not appear there.

  Confidential studies

• A Confidential study's key is used unencrypted only in the memory of the server handling it, for at most ten minutes, and is never written anywhere unencrypted.

  Confidential studies

• If the key service cannot be reached, a participant's answers wait on their device and are sent once it can.

  Confidential studies

• The score that raised an alert, and the values a schedule reads, are stored with the study's records under Google Cloud's standard encryption, not under the study's own key.

  Confidential studies

• Each researcher's key for Sealed studies is kept by Sigmer encrypted under a recovery code only they hold, and a Sealed study is published only once its key is kept by an account whose code is saved, or by an escrow.

  Sealed studies

• By default the team can give a colleague who joins later access to responses already collected; a study can instead fix its readers when each answer arrives, and its participants are told.

  Sealed studies

• Files and recordings can be collected only in a Sealed study. They are sealed on the participant's device and sent straight to storage, and a file Sigmer did not issue an upload for, or whose size or fingerprint does not match, is deleted.

  Sealed studies

• A Sealed study that runs in several parts and decides the next part from an answer sends that declared answer to Sigmer outside the seal, where Sigmer can read it.

  Sealed studies

• When participants are enrolled through a panel, their names and contact details are kept in a separate store, under their own key and their own grant, and a response carries only a participant code.

• A question that asks for a name keeps the answer inside the response, unless the study files people in a panel as they sign up, which moves those details into the panel. The default export leaves out every answer the study classes as a direct identifier.

• A study that schedules its parts stores each participant's time zone, read from their browser.

• Export responses as CSV, Excel or SPSS: coded by default, identified or anonymised when you need either.

• Access is by role. A person reads a project's responses only with analyst access or above on it, or as an owner or admin of its workspace, and a reviewer can read and comment on a project without access to its responses.

• Every read of a study's stored responses by a person or an API key is recorded in the workspace's audit log, with counts and never content.

• A read of a study's responses is recorded in the audit log when it begins, with how many sessions it covers, and the reader's access is checked again on every page of it.

• Each time a panel's names and contact details are sent to a researcher's device, it is recorded in the workspace's audit log.

• The audit log is hash-chained: each entry carries the hash of the one before it, so an edited or deleted entry breaks the chain. Workspace owners and admins can run the check, and keep the newest hash outside Sigmer to compare against later.

• A participant who declines the consent form leaves no response behind.

• When a participant agrees, the record keeps a fingerprint of the exact consent text they were shown and which optional agreements they ticked.

• A study can declare how long responses are kept. Each response is stamped with its destruction date when it arrives, and a nightly sweep erases what has passed it, files included. A participant still taking part keeps their schedule until it ends.

• When a study declares a retention period, its page states it, under the lock at the top.

• Withdrawing a person can mean two things, and the researcher chooses: stop, which ends their participation and deletes their answers where the study promised deletion on withdrawal, or forget, which deletes everything.

• A researcher can erase one response, one person across every study in the workspace, or a whole study. Erasing a study destroys its key.

• Responses delivered to your own storage are erased there, by you.

  Sealed studies, delivered to your own storage

• Erasure acts on the live database. A copy of the database taken before an erasure keeps what it held until that copy expires.

• Closing an account ends the person's memberships and invitations in every region, and is refused while a region cannot be reached.

• Each workspace keeps its data in one region, chosen when the workspace is created: the United States or Canada. A workspace stays in the region it is made in.

• A researcher chooses a home region once, when they sign up, and their personal workspace is kept there.

• In a workspace kept in the United States, stored responses and the servers that process them are in the United States.

• In a workspace kept in Canada, its projects, studies, team, responses, files, panels, schedules, audit log and logs, and the key that encrypts its Confidential studies, are stored and processed in Google Cloud's Montreal region.

• Wherever a workspace is kept, researchers' accounts and sign-in, the list of which workspaces each person belongs to, kept as identifiers, and each researcher's encrypted key for Sealed studies are held in the United States, and Sigmer's email to researchers is sent from there.

• A study in a workspace kept in Canada cannot email its participants yet, and Sigmer will not publish one that would.

• Google, and Amazon for participants' email, are United States companies, so keeping a workspace in Canada decides where its data is stored, not which country's courts can ask for it. For that, choose the Sealed level.

• An independent security audit report, such as SOC 2, or a third-party penetration test.

• A business associate agreement under HIPAA. Whether your study needs one is for your institution to decide.

• A data processing agreement signed with your institution. What Sigmer commits to a research team about participant data is in its terms of use, and the providers it uses are listed in its privacy policy.

• A region other than the United States or Canada, such as Europe. A study can deliver to S3-compatible storage you hold in the region you need.

• Moving a workspace to another region, or changing a researcher's home region once it is chosen.

• Single sign-on through your institution. Researchers sign in with an email address and password.

• Electronic signatures and a validation package for 21 CFR Part 11. Sigmer is not for regulated clinical trials.

• An adopted risk analysis and incident response plan. Both are drafted, and neither is adopted yet.

• A way for a participant to withdraw from inside the study. They contact the research team, who withdraw them.

Sigmer does not describe itself as compliant with any law or standard. Whether a study meets the rules that apply to it is for the institution to assess, and this page is written to help that assessment.

• This website sets no cookies, runs no analytics, and loads nothing from any other company's servers.

Write to hello@sigmer.io, and say which protection level the study uses. The page for ethics boards has the sentences a researcher can use in an application.