Security at Neuro Scan.

Architecture overview

The deployed architecture is designed so that, wherever possible, inference runs on-premises inside the hospital network. Raw scalp EEG would never leave the clinical environment by default. Only event summaries — timestamp, channel involvement, confidence, model version — would synchronize to the clinician dashboard, and only with the partner's explicit configuration.

For partners that opt into cloud-assisted inference, the cloud component will run in a single EU region with no replication outside the EEA, behind a private VPC, with TLS 1.3 in transit and AES-256 at rest. This will be configured per pilot rather than assumed.

Encryption — operational baseline

The following controls are in force today for our development, build, and corporate systems, and are the same controls that will carry over into the first clinical pilot:

• In transit: TLS 1.3 with modern cipher suites only. HSTS enabled with a 12-month max-age. Internal service-to-service communication uses mutual TLS.
• At rest: AES-256-GCM with envelope encryption. Encryption keys are managed in a hardware-backed key management service and rotated on a documented schedule.
• Backups: encrypted with separate keys, stored in a region distinct from primary, retained per the contractual retention period.

Access controls

• Single-sign-on with hardware-key MFA enforced for all employee access to production-class systems.
• Just-in-time, time-boxed access elevation for production debugging — every elevation logged and reviewed.
• Principle of least privilege; engineering staff will not have standing access to customer data once pilots open.
• Role-based access controls on customer-facing dashboards, with audit logs available to the partner from day one of pilot.

Clinical data handling — designed, not yet exercised

To be explicit: no patient EEG has yet been processed under a live Data Processing Agreement. The model below describes how we intend to handle clinical data once pilots open under signed DPAs with each partner site.

Special-category personal data (health data) will only be processed under a signed Data Processing Agreement with a clinical partner. We treat clinical data as the partner's data, not ours. We will not use clinical data for model training without an explicit, separately-signed research consent.

We support common clinical interoperability standards (HL7, FHIR R4) for data exchange. Patient identifiers can be tokenized at the network edge so that NSAS systems see pseudonymized records only.

Compliance & certifications

• GDPR — see our GDPR statement.
• ISO/IEC 27001 — implementation in progress; we operate to the standard's controls now, with certification audit on the roadmap.
• ISO 13485 — medical device quality management system; implementation in progress alongside CE-MDR submission.
• EU MDR (Regulation 2017/745) — classification and technical documentation work in progress; the platform is in pre-pilot phase (ethics-committee review open at four hospitals) and not yet CE-marked.

We do not claim certifications we do not yet hold. Current attestation status is shared on request under NDA.

Model integrity

Every model release is signed, versioned, and reproducible from the training pipeline. Deployment to a clinical partner is a manual, dual-controlled action — never an automated push from CI. Model version is logged with every detection event so clinicians can trace any alert back to the exact model that produced it.

Incident response

We maintain a documented incident-response plan with named roles, communication trees, and target containment times. For incidents that materially affect customer data, we notify affected partners within 24 hours of confirmation and follow up with a written post-incident report within 30 days.

For breaches involving personal data subject to GDPR, we notify the relevant supervisory authority within the 72-hour window required by Article 33, where the threshold is met.

Patient safety considerations

Security is not only about data — it is also about the physical and clinical safety of the patient wearing our hardware. The reference headset and its operating procedures are designed around six known risk categories:

• Skin irritation. Long-wear EEG electrodes can irritate skin, especially in sensitive or pediatric patients. We screen for skin conditions before any clinical use, monitor during wear, and specify hypoallergenic, latex-free electrodes and gels in the pilot kit.
• Infection risk. Reusable electrodes create a cross-contamination path if disinfection is incomplete. We enforce sterilization protocols on every reusable component, use medical-grade disinfectants, and supply single-use disposable electrodes where the clinical workflow allows.
• Allergic reactions to gels and adhesives. Pre-use allergy screening is mandatory in the pilot protocol; alternative gels and adhesive formulations are evaluated continuously, and emergency response materials must be on hand throughout any recording session.
• Fatigue and discomfort. Long monitoring sessions can cause headaches, restlessness, or distress — particularly in pediatric patients. We design the headset for low-pressure long wear, communicate session expectations clearly, and build rest periods into the protocol.
• Electromagnetic interference. EEG signals are sensitive to ambient electromagnetic fields. The device uses shielded cabling and grounded reference; the deployment guide includes environmental controls (mobile-device handling rules in the recording space, power-isolation requirements).
• Incorrect results. EEG acquisition has many failure points — loose electrodes, motion artifact, technician error. We mitigate through staff training, certification, routine equipment calibration, and software-level signal-quality monitoring that flags poor data before the model is asked to interpret it.

These categories will be itemized further in the clinical evaluation report submitted with the CE-MDR package; this list is the operating intent today.

Coordinated vulnerability disclosure

If you believe you have found a security vulnerability in our website, mobile app, or platform, please report it to clinical@nsai.fi. PGP key available on request.

Our commitment:

• Acknowledgement within 24 hours.
• Confirmed triage and disclosure schedule within 5 business days.
• No legal action against good-faith researchers who follow this process.
• Credit in any public advisory, unless you prefer anonymity.

What we ask:

• Do not exploit a vulnerability beyond what is necessary to demonstrate it.
• Do not access, modify, or exfiltrate data belonging to other users.
• Give us reasonable time to remediate before public disclosure — typically 90 days, longer if the issue is in a clinical pathway.

Out of scope

The following do not constitute security vulnerabilities for the purposes of our disclosure program: missing CSP headers without a demonstrated exploit, missing rate-limiting on contact forms, vulnerabilities in third-party services that we do not control, social engineering of NSAS staff, denial-of-service attacks.