Security & Responsible Disclosure

Contact and reporting

To report a potential vulnerability or security concern, email security@jooni.com. Our Vulnerability Disclosure Policy sets out what is in scope, our good-faith safe harbor for researchers, what to include in a report, and how we handle and disclose reported issues.

Data security and encryption

• Encryption in transit (TLS) and at rest across core services and storage.
• Wireless and device data transmissions are protected using modern, industry‑standard cryptography.
• We do not store payment card data; billing is handled by our payment provider. Typical customer data we store is minimal (e.g., business contact info such as email).

Access controls

• Least‑privilege, role‑based access; SSO/MFA enforced where supported.
• Customer data access is siloed and restricted to personnel with a business need; access is reviewed and auditable.
• Credential rotation and secret management practices are in place.

Key management & secrets

• Provider KMS used for encryption keys with scoped access and periodic rotation.
• Secrets stored in a managed vault; access is logged and reviewed.

Operational logging and change management

• Robust system logs across infrastructure and application layers for security, performance, and auditability.
• Device‑level records are maintained for fielded units (e.g., configuration, firmware version, and relevant events).
• Infrastructure‑as‑code and change workflows provide review/approval trails for system modifications.

Backups, disaster recovery, and continuity

• Regular encrypted snapshots and backups with off‑region redundancy.
• Defined RPO/RTO targets; periodic restore tests and fire‑drill exercises.
• Maintenance windows announced with reasonable notice; emergency maintenance when required for security/stability.

Incident response

• Documented playbooks for triage, containment, remediation, and post‑incident review.
• Customer communications align with our SLA and contractual obligations.

Subprocessors and shared responsibility

We rely on trusted infrastructure and service providers and apply security controls across our integrations. Our overall security posture depends in part on those providers—see Subprocessors for a current list.

Third‑party risk management

• Vendor onboarding includes security and privacy review appropriate to risk.
• Active vendor list is maintained and reviewed; material changes are communicated per our DPA.

Firmware & OTA security / compatibility

• Signed firmware, staged rollouts, and safe rollback paths; secure boot where applicable.
• Backward compatibility commitments with semantic versioning and deprecation windows to protect integrations.
• See Quality & Manufacturing for lifecycle testing, SBOM, and compatibility practices.

Assurance for regulated deployments

For government or mission‑critical deployments with geographic or regulatory requirements, additional documentation may be provided upon request under appropriate confidentiality.

Data residency

Regional deployment options may be available depending on product and capacity. Contact us to discuss geographic requirements.

Security certifications

We are actively maturing our security program. Public attestations (e.g., SOC/ISO) may be published here when available.

Security framework alignment

The frameworks below are the vocabulary most supplier questionnaires use. We name them so that buyers and assessors can map the controls published on this page onto their own questionnaires. Every mapping refers to a control already stated on this page or in our Trust Center, carried over with the same qualifications.

NIST Cybersecurity Framework (CSF) 2.0

Published controls correspond to each of the six CSF 2.0 functions as follows. This is a mapping of what we publish, not a statement of complete coverage of any function.

• Govern — vendor security and privacy review appropriate to risk, the maintained vendor list, and subprocessor change notice under our DPA map to Cybersecurity Supply Chain Risk Management (GV.SC).
• Identify — device‑level records for fielded units and the maintained vendor list map to asset and supplier identification; automated dependency and container scanning, and our vulnerability reporting channel (see Contact and reporting above), map to Risk Assessment (ID.RA), where CSF 2.0 places vulnerability identification and disclosure handling.
• Protect — encryption in transit (TLS) and at rest across core services and storage, cryptographically protected wireless and device transmissions, least‑privilege role‑based access with SSO/MFA where supported, provider KMS with scoped access, vaulted secrets, and signed firmware map to Protect.
• Detect — system logs across infrastructure and application layers, kept for security and auditability, are the record that supports Continuous Monitoring (DE.CM); this maps the logging control only and states nothing about monitoring or alerting.
• Respond — documented incident‑response playbooks and SLA‑aligned customer communications map to Respond.
• Recover — encrypted backups with off‑region redundancy, defined RPO/RTO targets with periodic restore tests, and safe firmware rollback paths map to Recover.

IEC 62443-4-1 and IEC 62443-4-2

IEC 62443-4-1 (Secure product development lifecycle requirements) covers how a product supplier develops and maintains its products; IEC 62443-4-2 (Technical security requirements for IACS components) covers what a component itself provides. Our published development and maintenance practices map to Part 4-1 as follows:

• Infrastructure‑as‑code and change workflows with review/approval trails map to secure implementation and change control.
• Automated dependency and container scanning, with periodic SAST/DAST where applicable, and periodic third‑party penetration testing with tracked remediation map to security verification and validation testing.
• Patch SLAs based on severity and exposure, and an SBOM available upon request, map to defect management and security update management.
• Signed firmware, staged rollouts, and safe rollback paths, with semantic versioning and deprecation windows, map to security update management and lifecycle communication.
• For Part 4-2, secure boot where applicable and per‑device serialization with device‑level records (configuration, firmware version, relevant events) correspond to component integrity and identification requirements.

ETSI EN 303 645 and NIST IR 8259A

ETSI EN 303 645 (Cyber Security for Consumer Internet of Things: Baseline Requirements) and NIST IR 8259A (IoT Device Cybersecurity Capability Core Baseline) are the device baselines most supplier questionnaires cite. They differ in scope: EN 303 645 sets provisions for the device and for its manufacturer, while IR 8259A lists technical capabilities the device itself provides. The list below maps our published device‑side controls to both standards and includes the one EN 303 645 manufacturer provision we publish against (vulnerability reporting), each labeled with the standard it corresponds to; cloud‑side controls such as key and secret management are mapped under CSF 2.0 and ASVS instead.

• EN 303 645 and IR 8259A — signed firmware with staged rollouts and safe rollback paths corresponds to “Keep software updated” and to the Software Update capability.
• EN 303 645 and IR 8259A — cryptographically protected wireless and device data transmissions correspond to “Communicate securely” and to the Data Protection capability.
• IR 8259A — per‑device serialization corresponds to the Device Identification capability.
• EN 303 645 — a public vulnerability disclosure policy with a named reporting contact (security@jooni.com) corresponds to “Implement a means to manage reports of vulnerabilities”.

OWASP Application Security Verification Standard (ASVS)

For our web applications and APIs, published controls map to ASVS requirement areas as follows:

• TLS for data in transit maps to communications security.
• Least‑privilege, role‑based access with SSO/MFA where supported maps to authentication and access control.
• Customer data access siloed and restricted to personnel with a business need maps to access control and data protection.
• Secrets stored in a managed vault with logged access map to configuration and secrets management.
• System logs across infrastructure and application layers for security and auditability map to security logging.
• Retention limited to what the service or law requires, with deletion or anonymization per policy, maps to data protection.
• Automated dependency scanning and periodic third‑party penetration testing map to dependency management and verification testing.

Data retention and deletion

• We retain customer data only as long as necessary to deliver the service or as required by law.
• Upon request or contract termination, data is deleted or anonymized per policy, subject to legal/backup constraints.

Vulnerability management

• Automated dependency and container scanning; periodic SAST/DAST where applicable.
• Patch SLAs based on severity and exposure; SBOM available upon request.
• Periodic third‑party penetration testing with tracked remediation.