Security at ClinikEHR
How ClinikEHR protects your practice and patient data — the safeguards built into the platform, what our Business Associate Agreement covers, and how to report a security concern.
This page describes what ClinikEHR does, at the level of policy rather than mechanism. For the fuller account of HIPAA safeguards and where responsibility sits between us and your practice, see HIPAA at ClinikEHR. For the contract itself, see the Business Associate Agreement and the Privacy Policy.
1. Our commitment
ClinikEHR is built for HIPAA-regulated work. A Business Associate Agreement is part of every account, available to every customer regardless of plan — accepting it at sign-up is what puts your workspace under that agreement. Our security controls are independently audited under SOC 2 Type II.
What follows sets out, specifically, the safeguards the platform provides. It is not a certification, and it is not a determination that any particular practice is compliant — compliance is a partnership, and HIPAA at ClinikEHR sets out what still remains your practice's own responsibility.
2. Data isolation between practices
ClinikEHR is used by many independent practices at once, and every clinical record belongs to exactly one of them. That boundary is enforced everywhere a record is read or written — not only in the screens you see, but where the data is held, so a request that somehow bypassed the application would still be refused. Working in more than one practice means two separate sets of access, never a merged view.
3. Encryption
Information sent to ClinikEHR is encrypted in transit, and it stays encrypted while it is held, including in backups. A browser connection requires TLS 1.2 or newer; the older, weaker versions of the protocol are refused outright, not merely discouraged. Where information travels between our own internal systems after it arrives, it continues to be encrypted and verified rather than crossing unprotected.
4. Access control
Access follows the minimum-necessary standard: people should reach only the information their job requires. Owners, managers and staff see different things by default, and individual abilities can be granted or withheld per person. A record can be restricted to the staff actually caring for that patient, so a colleague elsewhere in the practice does not see it in passing, and particularly sensitive notes or documents can be withheld from anyone not entitled to them. When care genuinely requires it, a restricted record can still be opened by giving a reason and a time limit, and that access is recorded for review afterwards.
5. Authentication
Everyone signs in as themselves — there are no shared logins — so a record's history names a person, not a role. A practice can require two-factor authentication for its whole staff; where it does, opening a clinical screen needs a session that has actually completed the second factor, not merely a signed-in one, and enrolment cannot be skipped or deferred. Sessions expire on their own rather than staying open indefinitely on an unattended screen, and sign-up and sign-in are protected against automated and scripted abuse.
6. Audit logging
Creating, changing, deleting and viewing a clinical record are all recorded automatically, with the person, the record and the time — including views, which is the access question asked about most often after the fact. Signing in and signing out are recorded too. The trail is kept for seven years, matching the HIPAA audit-control requirement, and only a practice's owners and managers can read it; everyone else, including the people it records, is refused.
7. Patient privacy tools
Patients can sign in to their own portal to see their documents, results and visit history, and to see which members of the practice opened their record and when. A patient can ask, from that same portal, that part of their record be restricted, and the request reaches the practice as a decision to make and record, not a message to lose.
8. Application security
Privileged operations — the kind that need to bypass a practice's normal access controls, decrypt a stored secret, or call an external service with elevated credentials — run in isolated backend functions that are never reachable from, or shipped to, the browser. Every code change is covered by an automated test suite before it can reach production, and we run automated security and configuration checks against our own systems on an ongoing basis.
9. Infrastructure & network
ClinikEHR runs entirely in the cloud, on infrastructure that is certified to recognised security standards and covered by its own business associate agreement with us. Our infrastructure sits behind a network layer that filters malicious and forged traffic before it reaches our servers, and the servers themselves do not accept a direct connection that bypasses that layer. Administrative access to the systems that operate the platform is restricted to authorized personnel and requires a second verification step beyond a password.
10. Data ownership, export & deletion
Your records are yours. You can export them at any time, as a spreadsheet or a bundle of them, without asking anyone, and every export is itself recorded in your audit log. If you close your account, billing stops immediately and your data is kept for a 30-day recovery window before it is permanently removed — export first, because nothing is recoverable once that window closes.
11. Incident response & breach notification
A breach is an impermissible use or disclosure of unsecured health information. Our commitments are in the Business Associate Agreement; the working timeline is this:
| Phase | When | What happens |
|---|---|---|
| Containment | Immediately | We contain the incident and preserve the evidence needed to work out what happened. |
| Assessment | Within 72 hours | We establish whether health information was actually reached, and whose. |
| Notice to your practice | Without unreasonable delay | Your practice is the covered entity. It cannot meet its own deadlines unless we meet ours first. |
| Notice to individuals | Within 60 days | Affected individuals are notified in writing, by your practice, with what we have given it. |
| Notice to HHS | Within 60 days | Reported at hhs.gov/hipaa. Breaches affecting fewer than 500 individuals are reported in the annual submission. |
| Notice to media | Within 60 days | Where a breach affects 500 or more individuals in a state or jurisdiction. |
12. Report a vulnerability
If you believe you have found a security vulnerability in ClinikEHR, tell us before telling anyone else. Email [email protected] with enough detail for us to reproduce it. Please avoid accessing, modifying or downloading any data beyond what your test requires, and do not include patient or account information you were not authorized to see in your report.
13. Contact
For anything else about security or compliance, write to [email protected]. If you are completing a vendor security review or a compliance questionnaire, say so and tell us the deadline — those are answered by a person, not a form.
This page describes what ClinikEHR does. It is not a certification, and it is not legal advice about your own compliance obligations.