A layered approach to protecting I am J systems, services, deployments, and information.
Our security program is risk-based and evolves with our technology, threat environment, service maturity, customer needs, and applicable obligations.
Controls are selected according to the sensitivity of data, criticality of systems, deployment model, and reasonably foreseeable impact.
Security considerations are incorporated into architecture, implementation, testing, release, and maintenance activities.
We use encryption and secure transport mechanisms where appropriate to protect data in transit and at rest.
Encryption is one component of a broader control environment that also includes access control, monitoring, retention practices, backups, and secure configuration.
Access to corporate and production resources should be limited to authorized users with a legitimate business need.
Controls may include unique identities, multi-factor authentication, role-based permissions, access reviews, session controls, and prompt removal of access when no longer required.
Operational safeguards may include hardened configurations, logging, monitoring, alerting, backup practices, change control, capacity management, and recovery procedures.
System configurations and controls are reviewed and improved as risks, technologies, and service requirements evolve.
Development practices may include peer review, testing, dependency review, environment separation, source control protections, and release procedures proportionate to the risk of the change.
Security defects are prioritized according to exploitability, exposure, affected data or functionality, and potential impact.
J-Spark Nexus and other enterprise deployments can introduce physical, connectivity, administrative, and local-environment risks.
Deployment security may include device configuration, administrative controls, physical safeguards, network segmentation, update procedures, customer responsibilities, and documented operating guidance.
We depend on selected third-party infrastructure and service providers. Relevant security, reliability, privacy, and continuity risks are evaluated proportionately.
No third-party service eliminates risk; therefore, architecture and operational planning should account for dependency failures and changed provider conditions.
We maintain processes for reporting, triaging, investigating, containing, remediating, and learning from suspected security incidents.
Notifications to affected parties, customers, authorities, or partners are made when required by law, contract, or responsible risk management.
Users and customers should protect credentials, maintain supported devices, apply security updates, configure integrations carefully, and report suspicious activity.
Enterprise customers are responsible for controls within their own environments unless a written agreement assigns responsibility otherwise.
Security researchers and users should report suspected vulnerabilities through our official contact channel and avoid actions that compromise privacy, availability, safety, or data integrity.
We ask reporters to provide sufficient detail for investigation and to allow reasonable time for remediation before public disclosure.
