Trust Center
Security
We are stewards of our customers’ data and do not take lightly the responsibility to keep that data safe. Our products are built with security in mind from day one and undergo ongoing reviews and testing to make sure we keep our customers’ data safe and secure.
Secure Development
Security is considered with every development effort. All developers are encouraged to learn about secure coding and practice principles of zero trust and least privilege when making architecture decisions.
1. We review our code for security vulnerabilities
2. We systematically update dependencies. When a systematic update is not possible, we manually update dependencies.
3. We use Static Application Security Testing (SAST) to detect basic security vulnerabilities in our codebase.
Data Encryption
Your data is always encrypted via industry best-practices using Transport Layer Security (TLS) at rest and in transit. Please view our SSLLabs reports here:
• app.clinical.ly
• clinical.ly
Audit Trails
All interactions with our applications are audited and logged. Logs are immutable and are never modified. Developers do not have access to production logs.
Permissions
It is imperative you control who can do what in your system. We built access controls best practices into our products. You have granular control over your data via team permissions and access settings.
Privacy
We believe that you own your data, and we are committed to providing you complete control over that data. Our SOPs clearly state how we protect your identity and your data. To report an issue with privacy, please read our Responsible Disclosure section. Please read our privacy policy here.
Data Retentions,
Deletion & Destruction
Upon a written request, we will provide you with all your data and will expunge your data from our systems. Data deemed to be owned by multiple parties will be deleted once all parties provide a written request to delete such data. We backup your data and validate those backups as per our SOPs.
Payment
Information
We do not store payment information. All electronic payments are processed through our payment provider, QuickBooks. Clinical.ly is PCI compliant for payment processing.
Employee
Access
Our strict, systematically enforced standard operating procedures prevent all employees, contractors, and administrators from gaining customer data access. AS per our SOPs, limited exceptions are made for specific individuals and customer support.
All Clinical.ly employees must undergo a background check, sign a non-disclosure
and confidentiality agreement when joining. We have a BAA in place with third parties.
Compliance
21 CFR Part 11 and Annex 11
Our products are validated, part 11 compliant with granular access controls and audit history. All data is stored in encrypted, redundant, high availability storage accessible to only authorized personnel.
ISO, HIPAA, and GDPR
Clinical.ly utilizes cloud services provided by AWS. Data never leaves AWS unless directed in writing by the customer. By exclusively utilizing AWS, Clinical.ly ensures compliance with all standards listed above. The complete list of standards with which AWS complies are listed here: https://aws.amazon.com/compliance/programs/.
Please read our privacy policy for details of how we comply.
Bug Bounty Program
We take cybersecurity very seriously and will reward anyone who finds vulnerabilities in our products and services while complying with our policies and terms of service. We encourage everyone who takes responsible disclosure seriously to participate in our bug bounty program. Please avoid automated testing. If you are a customer, please only perform security testing in your UAT and production accounts. Please do not disclose the vulnerabilities until we fix it. Rewards are done at our discretion and depend on the criticality of the vulnerability.
Please report vulnerabilities by contacting us via Contact Us page and include a note saying you are reaching out regarding our responsible disclosure program. Please be prepared to submit any applicable information, including a proof of concept. We are grateful for your time and will respond as quickly as possible. We will not take legal action if you follow our rules below.
- Let us know as soon as possible upon discovering a potential security issue. We will make every effort to resolve the issue quickly.
- Please provide us a reasonable amount of time to resolve the issue before disclosing externally.
- Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with the explicit permission of the account holder.
Please include in your report:
- Steps we should follow to reproduce the vulnerability and proof of concept.
- Any evidence of a successful attack, e.g., a print-screen of exploited screen or system.
- Explanation of how someone could carry out the attack in the wild.
Rules for us:
- Reply as quickly as possible to your submission and keep you updated.
- Not take legal action against you if you play by the rules.
- Reward you with a fair bounty.
Accepted vulnerabilities:
- Cross-Site Scripting (XSS)
- Open redirect
- Cross-site Request Forgery (CSRF)
- Command/File/URL inclusion
- Any authentication issues.
- Code execution or SQL injections
- Open ports that should be closed per security best practices.
- Account hopping
In-Scope:
*.clinical.ly
*.eregbinder.com
This bug bounty program does NOT include:
- Publicly accessible login panels – unless you were able to use such a panel to gain access
- Reports that state that software is out of date/vulnerable without a proof of concept
- Host header issues without an accompanying proof-of-concept demonstrating vulnerability
- XSS issues that affect only outdated browsers
- Stack traces that disclose information
- Deviations from best practices – unless you can demonstrate how someone might exploit our indiscretion
- Academic scenarios without proof of concept of how a bad actor can exploit such a scenario
- Vulnerabilities as reported by automated tools without explaining how the vulnerability can be exploited
- Reports from automated web vulnerability scanners without proof of concept
- Denial of Service Attacks
- Reflected File Download (RFD)
- Physical or social engineering attempts or issues requiring physical access to a victim’s computer, or user-interaction.
- Missing cookie flags on non-security-sensitive cookies.
- Missing security headers that do not present an immediate security vulnerability.
- SSL/TLS scan reports
- Bugs that don’t affect the latest version of browsers.
- Disclosure of public information and information that does not present significant risk.
- Bugs that have already been submitted by another user, that we are already aware of, or that have been classified as ineligible.
- If Clinical.ly determines the vulnerability presents an acceptable amount of risk.
- Things you should expect to receive little to no bounty for
- Most brute-forcing issues
Please contact us via Contact Us page if you have questions.
