Control point: NIH provides a separate Data Use Certification Agreement for controlled-access data. That document is not the same thing as approval of a particular remote Mac.

Fastest safe route: Confirm the project’s NIH access terms, your institution’s security requirements, and the actual service arrangement before moving data. If any responsible party has not confirmed the proposed environment, keep controlled data in an already approved location.

This guide is for:

  • PIs and project leads deciding whether a macOS analysis environment fits the approved research and who can authorize a change.
  • Data administrators and university IT checking access, data flows, retention, and service exit terms.
  • Graduate researchers and analysts who need to test macOS software without putting controlled files on an unapproved system.

The scope here is NIH controlled-access genomic data. It is not a blanket ruling for other research datasets or all remote computers. This is an approval-readiness guide, not legal advice. Only the relevant NIH and institutional officials can confirm what applies to your project.

Start with the project lead’s approval boundary

Before comparing Mac models or installing software, establish what the project is allowed to do. A working login, encryption, or a successful software test does not expand the approved research purpose.

The PI or project lead should compare the proposed use with the project’s access terms:

  • Research purpose: Does the planned analysis fit the purpose approved for this dataset? A new software workflow can still be a new use if it changes what the project does.
  • Authorized users: Are the people who will access the remote environment covered by the project’s approval and the applicable NIH requirements?
  • Access conditions: Do the project documents set limits on where or how data may be accessed, processed, shared, or retained?
  • Environment changes: Do the application materials, data-use documents, or institutional process require the computing environment to be described or reviewed when it changes?

NIH’s controlled-access data requirements and the project’s own Data Use Certification Agreement are starting points for this review. Read the actual terms attached to your project. Do not substitute a general summary for the controlling project documents.

NIH also publishes security best practices for users of controlled-access data. Use those practices to frame questions for your institution. They do not certify a particular provider or establish that a specific remote Mac meets your institution’s requirements.

Stop condition: If the project purpose, authorized-user list, or access conditions do not clearly cover the planned analysis, pause the transfer. Ask the institutional signing official, data-access contact, or other project authority to resolve the gap before proceeding.

Map the data path with your data administrator

The data administrator should draw the complete route, not just the connection from a researcher’s laptop to a Mac. Include every system and person that can hold, process, view, or retain project material.

Trace these stages:

  • Entry: How would data reach the remote environment? Identify the transfer method, credentials, and any staging location.
  • Processing: Which files will software read or create? Include scratch space, caches, temporary files, and intermediate outputs.
  • Access: List every person and account with potential access. Ask whether administrators or support personnel could access the host or its storage, and under what process.
  • Export: Identify which outputs may leave the environment, who may approve an export, and where approved results will go.
  • Retention: Locate snapshots, backups, logs, and copies created by the service or by project users.
  • Exit: Specify what happens to data, accounts, credentials, and retained outputs when the work ends or the service changes.

NIH’s user security best practices are relevant to the user’s handling responsibilities. NIH’s Code of Conduct for Genomic Data Users also sets expectations for responsible use. Neither encryption nor remote desktop access replaces the project’s approval terms or your university’s review.

A useful test is whether you can name every place a controlled file might exist, including temporary and backup copies. If the answer is “the provider handles that,” you do not yet have enough detail for an institutional review.

Scenario: the software runs, but the workflow is not approved

A graduate researcher needs a macOS-only tool to inspect genomic files. They log in to a remote Mac with their university account, confirm that the tool opens, and see that the connection is encrypted. Those facts show that the connection and software may work. They do not show that the project authorizes the transfer, that the service’s operators and storage arrangements have been reviewed, or that project copies will be removed as required.

The safer sequence is to test with public or synthetic files, document the workflow, and send that description to the PI, data administrator, and university security contact. Use controlled data only after the relevant officials confirm the proposed environment.

Have university IT review the actual service

The IT or information security reviewer needs service-specific facts. A product label such as “cloud Mac” is not a security assessment, and a provider’s general statement about encryption cannot answer every institutional question.

Ask for written answers to the following:

  • Operations: Who operates the host and supporting systems? Which personnel could access the environment, and how is such access authorized and recorded?
  • Identity and permissions: Can access be limited to named project users? How are accounts, credentials, and administrative permissions managed?
  • Data location and copies: Where can project data, backups, logs, or snapshots be stored or processed? Ask for the service’s documented answer; do not infer data location from a page name, region label, or network endpoint.
  • Incident handling: What is the process for reporting and responding to a suspected security incident? Who contacts the institution, and what information is available?
  • Service end: What return or deletion process is available? Can the service explain how it treats working storage, backups, and residual copies, and what written evidence it can provide?
  • Institutional terms: Can the service provide the technical and contractual materials the university needs to review? Do not assume a particular certification, agreement, or control exists unless the service provides evidence and the institution accepts it.

Separate the source of each requirement. NIH project terms, funding conditions, applicable law, and university policy are not interchangeable. The institution should decide which controls apply to this project and what evidence it requires from the service.

If the project involves electronic protected health information and HIPAA applies, have the institution assess that relationship separately. HHS explains that a cloud service provider that creates, receives, maintains, or transmits ePHI on behalf of a covered entity or business associate can have business associate responsibilities, including when the data is encrypted and the provider does not hold the decryption key. Review the HHS guidance on HIPAA and cloud computing with the institution’s privacy and security personnel. Do not conclude that a service is compliant based only on encryption or a provider’s self-description.

Let analysts test the workflow without controlled data

Researchers can still make progress while approval is pending. Use a public dataset or synthetic files to verify the technical workflow, but keep that test separate from the approval decision.

Ask the analyst to record:

  • The software name, version, installation source, and required dependencies.
  • The file formats and input size the workflow expects, without copying controlled files into the test.
  • Whether the analysis completes and whether the output can be reproduced.
  • Where temporary files, logs, and generated results appear.
  • How credentials are supplied and whether any data path bypasses the proposed controls.
  • What files the analyst expects to export and who would review those exports.

The NIH requirements for controlled-access data users and project documents should guide the permitted use. A test with synthetic data can establish that the software may run. It cannot establish that real project data may be uploaded, that the service is institutionally approved, or that the project’s data-use conditions have been met.

Weigh the options before choosing an environment

  • Use an existing institution-approved environment. This is the right fallback when it already supports the work and a remote service has not been reviewed. The tradeoff may be less choice of macOS software or a longer wait for access.
  • Assess a remote Mac. This may be worth evaluating when macOS-specific software is necessary and the project team can obtain the required service details. The review burden is real: you must establish the approved data path, users, controls, and exit handling.
  • Buy or dedicate a local Mac. A locally managed Mac may give the institution more direct control over the hardware, but purchase does not bypass project approval or university security review. The institution still needs to manage accounts, storage, backups, access, and disposal.

For a remote option, you can review the MACCOME service information and share the available materials with your university reviewers. A service page is a source to evaluate, not evidence that your specific project or institution has approved the environment.

Use this pre-transfer release checklist

Do not upload controlled files until the project team can check every item that applies. Record the evidence and the person who confirmed it.

  • [ ] The PI has matched the proposed analysis to the project’s approved research purpose.
  • [ ] The project team has checked the current Data Use Certification Agreement and NIH access requirements.
  • [ ] The responsible institutional contact has confirmed whether the proposed environment needs additional disclosure or approval.
  • [ ] The institution has reviewed who can access the host, storage, logs, and support channels.
  • [ ] The data administrator has documented entry, processing, export, backup, and retention locations.
  • [ ] The team has identified every project user and confirmed that access is authorized.
  • [ ] IT or information security has reviewed the actual service terms and available technical documentation.
  • [ ] If HIPAA applies, the institution’s privacy and security staff have assessed the service relationship and required agreements.
  • [ ] The team has defined how access will be revoked and how data will be returned or removed when use ends.
  • [ ] The analyst has completed a public or synthetic-data test and documented the workflow.
  • [ ] The project has written confirmation from the responsible institutional parties to proceed.

Decision rule: Continue only when project authorization, institutional review, service arrangements, and the data path are all clear. If one remains unresolved, use an environment the institution has already approved and keep controlled data out of the proposed remote Mac.

Close the loop when the work ends

Data exit is part of the design, not a cleanup task to improvise after the analysis. Before work begins, identify who will confirm that project files have been returned or removed, and which records the institution needs to retain.

At closeout, reconcile the original files, working copies, intermediate outputs, exports, logs, and backups against the approved data plan. Confirm that accounts and credentials are disabled or rotated as appropriate. Ask what written evidence the service can provide for its return or sanitization process. NIST’s Media Sanitization guidance, SP 800-88 Rev. 2 is a reference for media sanitization; it is not proof that a particular provider has performed a specific action. Your institution should decide what evidence is sufficient for the project.

The data owner should also decide whether results can be retained, whether they remain subject to project restrictions, and where the approved copy belongs. Do not treat “the subscription ended” or “the folder was deleted” as a complete record of data disposition.

Resolve common approval questions before transfer

Does encryption make the remote Mac acceptable?
No. Encryption is one control to review. It does not establish that the research purpose, users, service arrangement, data location, or retention process meets the project and institutional requirements. Ask the responsible officials to assess the whole data path.

Must the cloud environment be named in the NIH application?
Check the applicable application instructions, project documents, and institutional process. Do not assume that every project has the same disclosure requirement or that an existing approval automatically covers a later environment change. The institutional signing official or data-access contact can confirm whether an update or additional review is needed.

Can a de-identified sample be uploaded while approval is pending?
Only after the data owner and institution confirm that the sample may be transferred. De-identification alone does not prove that a file falls outside project restrictions or university policy. Use public or synthetic test files when that classification has not been confirmed.

Who approves the move?
There may be several separate decisions: NIH access conditions, project leadership, data governance, and university security or privacy review. Do not assume one person’s approval replaces another’s. Ask the institution to identify the officials responsible for the proposed dataset and service.

What must be checked after service ends?
Verify return or removal of working data, temporary files, exports, logs, and backups; revoke access; and collect whatever evidence the institution requires. The project data owner should decide which results can be retained and where. Use the service’s documented process and institutional retention rules rather than relying on an informal deletion confirmation.

A remote Mac is an option to evaluate, not an automatic extension of NIH approval. If your institution authorizes a remote macOS environment, gather the actual service and data-handling materials, then have the PI and university IT review them before transfer. You can start with MACCOME’s remote Mac options, but do not upload controlled data until the project and institutional reviewers have confirmed the specific arrangement.