Security Exhibit
The technical and organisational measures that protect the NSight360 platform and the data entrusted to it. Written so a reviewer can understand our security posture without an NDA.
- Applies To
- NSight360 Platform
- Data Class
- PHI, Restricted
- Hosting
- United States
- Last Reviewed
- Q2 2026
Ophthalytics processes Protected Health Information on behalf of healthcare providers. This Exhibit sets out, in plain terms, how that data is protected across the platform, its infrastructure and the people who operate it.
1 Purpose and Scope
This Security Exhibit describes the technical and organisational measures that Ophthalytics applies to protect the NSight360 platform and the data entrusted to it. It is written to give customers, prospects and their vendor risk teams a clear account of how the service is secured, without requiring an NDA to read.
The scope of this Exhibit is the NSight360 platform and its screening modules, the production environment in which they run, and the operational processes that support them. It does not cover the retinal cameras that capture images, the customer devices and browsers used to access the service, or the healthcare facility networks those devices sit on. Responsibility for those elements rests with the customer and their suppliers.
2 Security Governance
Security is owned by a Product Security function that reports to top management and is organisationally independent of engineering. This separation means that a decision to withhold a release on security grounds cannot be overruled by the team that produced the change.
Security requirements are set out in documented policies covering access control, secure development, logging, incident response and data handling. Policies are reviewed on a defined cycle and after any material change to the platform or its threat landscape. The full policy set is available to customers under NDA.
3 Data Classification and Handling
The platform processes Protected Health Information (PHI), including retinal images and patient demographics. All such data is classified as Restricted, the highest sensitivity tier, and is handled accordingly throughout its lifecycle.
Restricted data is never used outside the purpose for which it was provided. Production data is not copied into development or test environments, and no live PHI is used for testing. Where realistic data is needed for engineering work, it is synthetic or de-identified.
4 Identity, Access and Authentication
Access follows the principle of least privilege. Every user and operator is assigned a role scoped to their clinical or operational function, and permissions derive from that role rather than from the individual. Patient data is exposed only to roles with a legitimate need to see it.
Multi-factor authentication is enforced on administrative and privileged accounts, which are the highest-risk access paths. Access rights are reviewed on a recurring basis and reconciled against current responsibilities, and access is removed promptly on role change or departure. Access to patient records is logged to support monitoring, investigation and audit.
5 Encryption and Key Management
All traffic between client devices and the platform is protected with current transport encryption, and plaintext transmission of patient data is not permitted. Data at rest, including image storage and the application database, is encrypted using industry-standard algorithms.
Encryption keys are managed through the managed key services of our cloud infrastructure provider, with access to key material restricted to the roles that require it and logged in the same way as other privileged actions.
6 Cloud Infrastructure and Network Security
The platform is hosted entirely on Amazon Web Services in a United States region. It runs inside a private virtual network with segmentation between tiers, and public entry is limited to a load-balanced ingress protected by a web application firewall.
The production environment is isolated from development and test. Administrative access to production infrastructure is restricted, authenticated and logged. A Business Associate Agreement is executed with the cloud infrastructure provider, and the physical security of the underlying data centres is the provider's responsibility under that agreement.
7 Secure Development and Change Management
Changes to the platform move through a defined development lifecycle with peer code review, automated testing and static analysis before release. The depth of verification applied to a given component reflects its safety and security significance.
Releases are controlled through a documented process with a pre-release checklist and a recorded release decision. Where a design input derives from a security control, that link is recorded so the control cannot be removed without the associated risk being reassessed.
8 Vulnerability Management and Penetration Testing
Dependencies are monitored for known vulnerabilities, and a software bill of materials is maintained for the platform's components. Identified issues are triaged by severity and remediated within timeframes set by their risk.
The platform and its screening modules undergo independent penetration testing covering authentication, authorisation, API security and access control. Findings are tracked to closure through a formal remediation process, and fixes are confirmed by re-testing. A summary of the most recent test is available to customers under NDA.
9 Logging, Monitoring and Detection
Security-relevant events across the application and infrastructure are logged centrally and retained for investigation and audit. Monitoring and alerting are configured so that anomalous or unauthorised activity is surfaced to the team responsible for responding to it.
Access to logs is itself restricted and recorded, and logs are protected against tampering so that they remain reliable as a record of what occurred.
10 Incident Response and Breach Notification
A documented incident response process defines how events are detected, triaged, escalated, contained and resolved, and how lessons are fed back into the platform and its controls.
Where an incident involves Protected Health Information, affected customers are notified in accordance with HIPAA and the terms of the applicable agreement, within the timeframes those terms require. Suspected vulnerabilities can be reported to us at any time at support@ophthalytics.com.
11 Resilience, Backup and Continuity
Patient data is backed up on a regular schedule, and backups are encrypted and protected to the same standard as production data. Recovery procedures are defined so that service and data can be restored within objectives agreed with customers.
The platform is built on managed, redundant cloud services to reduce the impact of individual component failures on availability.
12 Personnel Security and Training
Personnel with access to Restricted data are subject to appropriate pre-engagement checks and are bound by confidentiality obligations. Access is granted only after those obligations are in place and only to the extent the role requires.
Staff receive security and privacy training on joining and on a recurring basis thereafter, with additional guidance for roles that carry elevated access or handle PHI directly.
13 Subprocessors
Ophthalytics uses a limited set of subprocessors to deliver the service, the most significant being the cloud infrastructure provider that hosts the platform. Subprocessors that may process PHI are engaged under written agreements that flow down the relevant confidentiality and security obligations, including a Business Associate Agreement where required.
A current list of subprocessors is maintained and made available to customers, and customers are informed of material changes so that they can exercise any rights the agreement gives them.
14 Assurance, Audit and Certification
Ophthalytics maintains a quality management system established in accordance with ISO 13485:2016, described in our Quality Statement, within which security is treated as an integrated discipline rather than a separate function.
A SOC 2 Type II readiness programme is underway, covering the Security trust services criteria, with controls being implemented and evidenced ahead of an independent audit. The report will be published on completion. Until then, we support customer assurance through this Exhibit, a self-assessment questionnaire, and evidence released under NDA.
Have any further questions?
Feel free to reach out to us — our security team reads every message, and we would rather answer a question twice than leave it unanswered once.