Where the data lives: the security plan a WGU file has to carry
Name the place, the people and the day it ends. Almost every plan a board sends back failed on one of those three, and almost always because it offered an assurance where a specific was wanted. Data will be kept secure is not a plan; it is a hope with a passive verb attached.
Say where every copy sits, who can open each one, whether anything still traces back to a person, and what event triggers destruction. Then check that the consent sheet promises exactly what the plan delivers — no more, and no less.
What is the plan actually answering?
One line of the approval criteria. Before approving anything, a board has to find under 45 CFR 46.111 that the arrangements are adequate, where the case calls for them, both for participants' privacy and for confidentiality of whatever is collected. Your plan is the evidence for that finding, which is why an adjective cannot carry it. The board is not deciding whether you intend to be careful. It is deciding whether the arrangements you describe would hold if someone left a laptop on a train.
The two words in that criterion are not synonyms, and the standard human-subjects curriculum separates them deliberately. Privacy belongs to people: the control someone has over who observes them and under what conditions. Confidentiality belongs to information: what you have undertaken to do with what they gave you. A project can respect privacy beautifully during collection and then breach confidentiality in a spreadsheet a week later, and the plan has to speak to both halves.
WGU's own published application asks the question in a form worth reading closely. It asks you to describe the steps that will ensure anonymity or confidentiality for participants and their data, and how you will deal with personal identifiers — and then adds a clause most candidates read straight past. Where neither anonymity nor confidentiality will hold for participants, the form wants the reason the design needs it that way. There is a legitimate answer to that clause. There is no answer that consists of not noticing it.
Where will the data live, and who can open it?
Write the plan as an inventory, not as a paragraph. Every copy of every record, from first capture to final archive, and what protects it at each stop. Boards return plans that describe the destination and skip the journey — because the journey is where the losses happen.
- Capture. Paper on a clipboard, a tablet, a survey platform, a recorder. Name the tool and say what is switched on: a lock code, an account tied to the organisation rather than to a personal address, transcription that stays on the device.
- Transfer. The step nobody writes down and the one most often failed. If a file moves by email, say so and say what is in it. If it moves on a memory stick, say whether the stick is encrypted.
- Working storage. One named location — an account you can name, on a service you can name — rather than my computer. If a working copy exists on a personal laptop for analysis, say that too; a plan that pretends otherwise will be contradicted by your own methods section.
- Access. A list of roles, not a reassurance. Who else reads it: a chair, a statistician, a transcriptionist, a colleague checking coding. Anyone outside the project team who touches identifiable material should be under a confidentiality undertaking, and the plan should say so.
- Backup. A copy is a copy. If the service keeps versions or a recycle bin, that is another place the record lives, and the destruction line has to reach it.
The published WGU example is instructive here, and worth updating rather than copying. In it, each participant is assigned a code, the list linking names to codes is held in a locked file, names appear nowhere in the report, findings are given in aggregate, and the list is shredded once analysis is finished. That is a sound structure. Written today, most of those nouns are digital, and the plan has to name their digital equivalents with the same specificity — which locked file, held where, and shredded by what mechanism.
Is your dataset de-identified, or only coded?
This is the question that decides which branch of the tree your project is on, so it deserves a straight answer rather than a hopeful one. Coded means a key exists somewhere that could put names back onto rows. De-identified means no such key exists anywhere you control. Storing the key in a different folder, or on a different drive, or with a colleague, does not convert one into the other.
The regulations reach the same place from two directions. The Common Rule turns on whether identity is readily ascertainable from the information you hold. The HIPAA de-identification standard is more mechanical: strip the eighteen categories of identifier listed at 45 CFR 164.514, then confirm you know of nothing in the remainder capable of singling somebody out. Where a code is retained to allow re-identification, that provision sets conditions on the code itself — it must not be derived from anything about the person, it must not be used for any other purpose, and the means of re-identification must not be disclosed. A code built from initials and a birth year fails the first of those before it is written down.
| Field you were planning to keep | The problem | What holds up instead |
|---|---|---|
| Medical record or employee number | A listed identifier, and one that resolves instantly inside the organisation | A study code with no derivation from the original number |
| Admission or visit date | Dates finer than a year are listed identifiers, and on a small unit a single date is nearly a name | Days elapsed from an index event, or the month alone if the analysis survives it |
| Role plus shift plus unit | No single field identifies; the combination describes exactly one person | A broader role category, or a footnote saying small cells are suppressed |
| An audio recording of an interview | Voice is a biometric identifier, so the file is identifiable however it is labelled | Transcribe, remove names inside the transcript, then destroy the audio on a stated trigger |
| A distinctive verbatim quotation | Colleagues recognise a phrasing long before they recognise a code | Paraphrase, or seek explicit agreement to quote and say so in the consent sheet |
| The linking key, kept in case | Its existence makes everything else identifiable, wherever it is stored | Either commit to holding it under stated controls, or destroy it at a stated point and say when |
Deciding this early is cheaper than deciding it late. A project that will never need to re-contact anyone, and will never need to add a later measurement to an earlier one, has no reason to keep a key — and dropping it moves the whole file onto a lighter branch, which is a design decision rather than a paperwork trick.
What does the destruction line have to say?
It has to name a trigger and a method, and the trigger has to be an event rather than an intention. Once analysis is complete is an event. When no longer needed is not, and a reviewer will say so. Write the sentence so that somebody who has never met you could tell, on any given day, whether the moment has arrived.
Three further things belong in the same paragraph. Which items go — the key first, usually, and often well before the dataset. How they go, in terms that match where they live: shredding for paper, a described deletion for cloud storage including whatever the service keeps in reserve. And what survives, because something usually does. Where WGU's handbook or a facility's own policy sets a retention period for records tied to the project, the plan states that rather than promising a deletion that policy will not permit. Retention rules of that kind belong to WGU's current handbook or IRB portal, and to the site's policy where records came from the site.
Which other documents does the plan have to agree with?
Everything that describes the same facts, which is more of the folder than people expect.
- The consent sheet. Its confidentiality element states how far identifying records will be held in confidence. If the plan keeps a key and the sheet promises anonymity, the file contradicts itself on its most sensitive point. Both pages get revised together or neither does — see the consent requirements.
- The recruitment wording. A flyer that says anonymous has made a promise the plan must keep. Check it against the recruitment materials.
- The site permission page. If records come from a facility, the page should name those records and whether they arrive with identifiers attached; the plan then picks up where that sentence leaves off.
- The methods narrative. A method describing a follow-up measurement on the same individuals requires a key, whatever the plan says.
- The instruments. A survey with a free-text box invites identifiable answers. Either the plan says how those are handled, or the box goes.
A last habit, small and unglamorous: write the plan in the present tense of an ordinary working week. Not what will be done in principle, but what happens on a Tuesday when a transcript arrives. Plans written that way are shorter, and they are the ones that survive contact with the project.
What to do next
List every copy of every record your design creates, including the ones that feel too obvious to write down, and put a lock and a name against each. Decide the key question honestly — keep one under stated controls, or hold none at all — and let that decision drive the consent wording rather than the other way round. Then read the confidentiality sentence in your consent sheet and ask whether the plan you have just written actually delivers it.
If you would rather hand the branch over, the free application review will read what exists and say where the project honestly sits, including when a clean file needs nothing from us. Where it does, we build the plan alongside every other document, keep the pages matched as the design moves, file the submission and answer each reply until approval arrives. Your data stays yours; the board's decision stays the board's. See how it works, read the FAQ, or send us what you have.
Request the free application review
Sources
- The approval criterion your plan answers: adequate provisions to protect privacy and maintain confidentiality — 45 CFR 46.111(a)(7) — Cornell LII, 45 CFR 46.111
- How the regulations define private information that still identifies somebody — 45 CFR 46.102 — Cornell LII, 45 CFR 46.102
- The eighteen identifier categories, the expert-determination route, and the conditions on any re-identification code — 45 CFR 164.514 — Cornell LII, 45 CFR 164.514
- The confidentiality element of consent — 45 CFR 46.116(b) — Cornell LII, 45 CFR 46.116
- Western Governors University Institutional Review Board, Request for Approval to Conduct Research (the anonymity and identifiers question, the clause on designs that are neither anonymous nor confidential, and the published coding, locked-list and shredding pattern) — aliciabatesmedlt.weebly.com/uploads/1/2/6/3/126370100/request_for_approval_to_conduct_research__1_.pdf
- Privacy and confidentiality treated as separate constructs in the standard curriculum — CITI Program, the HSR series — about.citiprogram.org, HSR series
Routes, forms and portal wording at WGU move over time. Where this page disagrees with WGU's current handbook or IRB portal, believe the portal. This desk is an independent practice; it is not part of Western Governors University and does not speak for it.