Data Handling & Security
A plain-language statement of the boundaries Merindale uses when deciding what information is needed, where work should happen, and which controls belong around a client engagement.
Public website boundary
The public Merindale website is for general business information and initial inquiries. It is not intended to receive clinical source data, patient records, study-subject identifiers, sponsor-confidential datasets, credentials, or regulated research records.
Minimum necessary information
Merindale's operating principle is to request only the information needed to perform an agreed scope. Before client data is shared, the parties should define what data is required, who may access it, where it may be stored, how it may be transmitted, and when it should be returned or deleted.
Client systems first where practical
When a project can be completed inside a client's approved systems, Merindale prefers that model over unnecessary copying of data into separate tools. Access should be tied to the work, limited to the people who need it, and removed when it is no longer required.
Align with client controls
Clinical research organizations, health systems, sponsors, and sites may have their own security standards, identity controls, approved platforms, data-classification rules, retention requirements, and vendor-review processes. Merindale should work within those requirements when they apply rather than imposing a separate technical environment simply because it is familiar to us.
Sensitive and regulated information
Merindale will not assume that ordinary email, consumer file sharing, or a public scheduling form is appropriate for sensitive research information. If an engagement may involve protected health information, personally identifiable information, sponsor-confidential materials, or other regulated data, the necessary contractual, technical, and access controls should be established before access is granted.
Technology and service providers
Merindale may use third-party technology providers for hosting, identity, email, scheduling, collaboration, cloud services, security, or analytics. Provider selection and configuration should be appropriate to the sensitivity and contractual requirements of the specific engagement rather than assumed from the public website stack.
Access and offboarding
Access should be tied to named users, protected with strong authentication where supported, and reviewed when project roles change. At the end of an engagement, client access should be removed and client information handled according to the applicable agreement, client instruction, and retention requirements.
Incidents and concerns
If Merindale becomes aware of a suspected security or confidentiality issue involving client information, the response and notification process should follow the applicable client agreement, system-owner requirements, and relevant legal obligations.
Engagement-specific controls
This public statement is not a security certification and does not replace a client security review, business associate agreement, data-processing agreement, confidentiality agreement, sponsor requirement, institutional requirement, or other engagement-specific obligation.
Related commitments
See our Privacy Notice for public website data practices and our Professional Standards for the principles that guide confidentiality, scope, collaboration, and client work.