Security you can check, not badges to take on trust.
Healthcare revenue data deserves care, and claims about protecting it deserve evidence. This page describes the controls that are actually in place.
How this website is built
Controls in the code today
- Secrets encrypted at rest
- Permissions checked on the server
- Append-only audit log
- Framework-managed sign-in
Response headers in production
- Content-Security-Policy
- default-src 'self'
- X-Frame-Options
- DENY
- X-Content-Type-Options
- nosniff
- Strict-Transport-Security
- max-age=63072000
At a glance
A marketing site, not a PHI system
No patient records, claim files or remittance data are held here.
Framework-managed sign-in
Password hashing and sessions are handled by the CMS, never hand-rolled.
Analytics wait for consent
Optional analytics load only after a visitor accepts them.
No custom scripts
There is no field for pasting JavaScript. Tags go through Tag Manager only.
The PHI boundary
This website is not a PHI system
Kitronixe Solutions deliberately separates its public website from the systems that process healthcare data. This site is a marketing and content platform. It holds no patient records, no claim files, no remittance data and no protected health information, and it is not built to.
Production revenue cycle work and Kitronixe software products operate in separate, appropriately secured infrastructure with their own access controls and contractual protections.
What the forms on this site never ask for
- Patient names
- Medical records
- Claim files and EOBs
- X12 files
- Diagnoses
- Treatment information
Every free-text field carries a warning not to include patient information. As a safety net, a submission that looks as if it contains such information is flagged so an administrator can review and remove it.
Please do not send us patient information here
Website forms and ordinary email are not a secure channel. Do not send patient names, medical records, claim files, EOBs, X12 files, diagnoses or treatment information through this site. If you need to share protected health information, contact us first and we will establish an appropriate channel with the necessary agreements in place.Implemented today
How this website is protected
Controls that are implemented today, not aspirations.
Encrypted in transit
The site is served over HTTPS with HSTS, and administrative credentials are never transmitted over an unencrypted connection.
Encrypted credentials at rest
Configuration secrets stored by administrators — mail credentials, integration keys — are encrypted with AES-256-GCM using a key held outside the database. They are never displayed back, even to the administrator who set them.
Role-based access control
Every administrative action is authorised server-side against a granular permission model, resolved as explicit deny, then explicit allow, then the role default. Hiding a control in the interface is treated as a convenience, never as a security boundary.
Append-only audit logging
Sign-ins, permission changes, publishing, credential replacement and configuration changes are recorded. Entries cannot be edited or deleted through the application.
Secrets kept out of responses and logs
A decrypted credential is never returned to the browser, and credential-shaped values are scrubbed from anything written to a log or shown in an error.
Abuse protection
Administrative sign-in locks after repeated failures. Public forms are rate limited and screened for automated submission.
Content and upload safety
Published content is rendered from structured data rather than raw HTML, so stored content cannot introduce scripts. Uploads are restricted by type and size, and SVG files are sanitised before storage.
No way to paste in code
The admin panel has no custom-JavaScript field and never will. Marketing tags are managed through Google Tag Manager, the single controlled mechanism.
Validated redirects
Redirect destinations must be a path on this site or a genuine web address, which prevents open redirects. Redirect loops are rejected when saved.
Security headers
A strict Content-Security-Policy, frame protection, MIME-sniffing protection and a restrictive Permissions-Policy are applied in production.
End to end
The path an admin request takes
Six checks, in order, every time someone changes something in the admin panel.
- Step 1
Origin checked
Authenticated requests are accepted only from the site’s own addresses.
- Step 2
Session verified
Framework-managed sign-in, with lockout after repeated failures.
- Step 3
Permission resolved
Explicit deny, then explicit allow, then the role default, on the server.
- Step 4
Input validated
Form submissions and technical settings are validated on the server before saving.
- Step 5
Secrets kept sealed
Stored credentials are masked before any response leaves the server.
- Step 6
Action recorded
The change is written to an audit log the application cannot edit.
Our commitment
How we talk about security
Plenty of healthcare vendors display compliance badges that do not mean what a reader assumes. We would rather be straightforward.
If you are running a vendor security review, contact us. We will answer your questionnaire directly rather than pointing you at a page of logos.
There is no such thing as "HIPAA certified"
HIPAA has no certification programme. Any vendor claiming to be HIPAA certified is describing something that does not exist. Compliance is an ongoing obligation, evidenced by controls and agreements — not a badge.
Attestations are named, with their scope and date
Where Kitronixe holds an independent audit or attestation, it is named on this page together with its scope and the date it was issued.
We do not publish security statistics we cannot evidence
No uptime figures, breach counts or response times appear here without measurement behind them.
Reporting a vulnerability
If you believe you have found a security issue in this website, please tell us before disclosing it publicly. We will acknowledge your report and keep you informed while we investigate.
Use the contact form and mark your message as a security report.
Security questions
What reviewers ask first
How information is handled, who can reach it, and where this website stops.
How do you handle protected health information?
Production revenue cycle work happens in secured infrastructure under the appropriate agreements. This website is deliberately separate and is not used to receive patient information.
Questions from your security team?
We would rather answer them properly than have you guess from a web page.