Cloud Storage Policy Guide for Fecal Microbiota Transplant Programs

A clear cloud storage policy helps your fecal microbiota transplant (FMT) program protect patient and donor information, maintain usable clinical records, and plan for outages or vendor changes. Use this guide to set practical safeguards, then have your privacy, security, clinical, and legal leads adapt the policy to your program’s services and applicable requirements.

What data should an FMT program store in the cloud?

Store records needed to support care, safety, program operations, and any applicable research or regulatory obligations. Set a documented purpose for each category; avoid collecting or retaining information simply because cloud capacity is available.

• Patient records: identifiers, relevant clinical history, eligibility assessments, consent, treatment details, follow-up, and adverse-event documentation.
• Donor and product records: donor screening and testing results, donation dates, product or specimen identifiers, processing and storage details, and records linking a product to its donor and recipient when needed.
• Program records: policies, staff training records, access approvals, security incident records, vendor agreements, and applicable research or quality records.

For FMT uses covered by FDA’s enforcement-discretion policy, its stated conditions include patient consent and donor and stool qualification through screening and testing under the treating provider’s direction. The policy is limited to FMT for C. difficile infection not responsive to standard therapies; it does not cover every FMT use. Keep the records your program needs to demonstrate that applicable conditions were met. See FDA’s FMT enforcement policy guidance.

How should patient and donor records be classified and access-controlled?

Classify records according to their sensitivity and intended use. Treat identifiable patient records as protected health information (PHI) when HIPAA applies, and protect donor health information with comparable care. Keep direct identifiers separate from coded clinical, specimen, or product data where practical; restrict access to any file or system that can reconnect a code to a person.

Use role-based access control (RBAC) to give each workforce member only the access needed for their assigned duties. For example, a clinician may need patient treatment records, while a lab user may need coded product and testing details. Review permissions when staff change roles or leave, require individual accounts rather than shared logins, and establish a controlled process for urgent or emergency access.

HIPAA requires access controls, unique user identification, and audit controls for systems containing electronic PHI; RBAC is one practical way to organize access, not the only permitted method. Define who approves access, how often permissions are reviewed, and how exceptions are documented. See HHS’s HIPAA Security Rule summary.

What safeguards protect FMT data during storage and transfer?

Build safeguards around a documented risk assessment, covering both the cloud service and the devices, accounts, and workflows used to reach it. Protect access with strong authentication, prompt account removal, secure device settings, and staff guidance on handling sensitive files.

• Encryption at rest: Evaluate encryption for stored records, database files, exports, and backups. Restrict and protect encryption keys separately from the data where feasible.
• Encryption in transit: Use protected connections and approved transfer methods when records move between users, systems, labs, or vendors. Avoid sending identifiable records through unapproved channels.
• Audit logging: Record and review activity such as sign-ins, access to sensitive files, changes, downloads, and administrative actions. Define how suspicious activity is escalated.
• Integrity and recovery: Protect records from unauthorized alteration or destruction, and test whether the program can restore usable data after an outage or incident.

Under the current HIPAA Security Rule, encryption is an addressable implementation specification: the organization must assess whether it is reasonable and appropriate, implement it when appropriate, or document its decision and use an appropriate alternative when warranted. Addressable does not mean automatically optional. See HHS’s guidance on HIPAA encryption.

HIPAA also requires safeguards for electronic PHI in transmission and mechanisms to record and examine activity in systems that contain or use it. See HHS’s HIPAA Security Rule summary.

How do HIPAA and other privacy requirements apply to cloud storage?

HIPAA applies based on the organization’s role and activities; an FMT program is not automatically a HIPAA covered entity simply because it handles health information. Health care providers that conduct certain electronic transactions can be covered entities. If your program is covered by HIPAA, its Privacy, Security, and Breach Notification obligations apply to PHI it creates, receives, maintains, or transmits.

When a cloud provider creates, receives, maintains, or transmits electronic PHI on behalf of a covered entity or business associate, the provider generally acts as a business associate. The covered entity or business associate must have a HIPAA business associate agreement (BAA) with the provider. HHS states that this applies even when the provider stores only encrypted PHI and does not hold the key. See HHS’s cloud computing guidance.

A BAA should address permitted uses and disclosures, safeguards, incident reporting, relevant subcontractors, and what happens to PHI when the agreement ends. A signed BAA does not by itself make your program compliant: you remain responsible for assessing risks, configuring your service appropriately, and meeting your own applicable obligations. See HHS’s business associate contract guidance.

Also check applicable state privacy and medical-record laws, research requirements, and FDA or protocol obligations relevant to your program. Requirements can depend on the particular service, study, product, and jurisdiction. Get legal or compliance review rather than assuming one general retention or privacy rule covers every FMT record.

How should backups, retention, and secure deletion be managed?

Document a data retention schedule that identifies each record category, its retention trigger, the applicable authority or operational need, and who approves disposition. HIPAA does not set a general retention period for medical records; state laws generally govern how long medical records must be retained. HIPAA does require certain compliance documentation to be kept for six years from creation or the date it was last in effect, whichever is later. That six-year rule is not a universal medical-record retention period. See HHS’s medical-record retention FAQ and HHS’s Security Rule documentation requirements.

Maintain retrievable backups and a recovery plan, and test restoration on a schedule suited to your program’s risks and clinical needs. Define which records are backed up, who can restore them, how backup copies are protected, and how the program will continue essential work during an outage. HHS describes data backup, disaster recovery, and emergency-mode operations as parts of the HIPAA Security Rule’s contingency planning requirements. See HHS’s contingency planning guidance.

When records reach the end of their approved retention period, delete them securely from active storage and address copies in backups, exports, and vendor-managed systems. Document any legal hold or other reason to suspend deletion. Include return or destruction of PHI in your vendor offboarding process: a BAA must provide for return or destruction when feasible, and if that is infeasible, protections and limits on further use must continue. See HHS’s cloud-provider termination guidance.

What should an FMT cloud storage policy include?

Write the policy so staff can follow it in everyday work and during an incident. Include:

• The policy’s scope, purpose, owner, review schedule, and records covered.
• Data classification rules for patient, donor, specimen, product, research, and administrative records.
• Approved cloud systems, file-sharing methods, and rules for storing or transferring data.
• Access approval, role-based permissions, authentication, account reviews, and emergency access procedures.
• Encryption expectations, key management responsibilities, audit logging, and log review.
• Backup frequency, recovery responsibilities, restoration testing, and outage procedures.
• A data retention schedule, deletion procedures, legal-hold process, and vendor offboarding steps.
• Incident reporting, investigation, escalation, and applicable breach-response procedures.
• Vendor due diligence, BAA requirements where applicable, subcontractor expectations, and data-return arrangements.
• Staff responsibilities, training, enforcement, and records showing policy approvals and reviews.

Assign an owner to verify the policy against actual cloud settings and workflows. Revisit it when your services, vendors, threats, or applicable requirements change.

What are the limitations of cloud storage for FMT records?

Cloud storage can improve access and recovery, but it does not remove your program’s responsibility to manage data. Misconfigured permissions, compromised credentials, accidental sharing, unavailable services, and unclear vendor arrangements can still put records at risk. Encryption alone does not address every confidentiality, integrity, or availability concern.

Assess how you will access and export records if a provider has an outage or your contract ends. Confirm that the service supports the backup, logging, security, and data-return features your policy depends on. HHS does not endorse, certify, or recommend specific cloud products as “HIPAA compliant,” so evaluate the provider and service configuration rather than relying on a marketing label. See HHS’s cloud computing guidance.

In short, an effective cloud storage policy defines which FMT records you keep, who can access them, how they are protected and recovered, and when they are securely removed. Align those decisions with your program’s risk assessment, vendor agreements, and applicable retention and privacy requirements.

FAQs.

Does an FMT program need a business associate agreement with its cloud provider?

If your program is a HIPAA covered entity or business associate and the cloud provider maintains or otherwise handles electronic PHI on its behalf, generally yes. HHS states that storing encrypted PHI without the decryption key does not by itself exempt a cloud provider from business associate status. Whether HIPAA applies to your program depends on its role and activities; confirm the arrangement and agreement with your privacy or legal lead.

How should cloud access to FMT patient records be controlled?

Use individual accounts and role-based permissions that limit each person to the records needed for their work. Review access regularly and when staff roles change, remove access promptly when it is no longer needed, and review audit logs for unusual activity. HIPAA requires appropriate access controls and audit controls for systems containing electronic PHI; RBAC is a practical policy choice for implementing those controls.

Should FMT records be encrypted in cloud storage?

Encryption is an important safeguard to assess for stored records, backups, and transfers. Under the current HIPAA Security Rule, encryption is addressable, so your program must determine whether it is reasonable and appropriate for its risks, implement it when appropriate, or document the decision and use an appropriate alternative when warranted. Encryption supports protection but does not replace access controls, backups, risk management, or other safeguards.

How long should an FMT program retain records in the cloud?

Set the period in a data retention schedule based on the applicable state and federal requirements, research or protocol obligations, and operational needs for each record category. HIPAA does not establish a general medical-record retention period, although it does require certain HIPAA compliance documentation to be retained for six years from creation or the date it was last in effect, whichever is later. Apply required safeguards for as long as PHI is maintained, including during deletion or disposition.