Security Overview

1. Security Philosophy

elyXion designs and operates services using risk-based security, least privilege, defence in depth, secure defaults, separation of duties where practical, and continuous improvement. We draw on Microsoft security guidance, Zero Trust concepts, cloud well-architected practices, and recognised industry controls where relevant.

Alignment is not certification. elyXion does not claim ISO 27001, SOC 2, NEN 7510, Cyber Essentials, Microsoft Solutions Partner, or other certification unless a future statement names the certified entity, scope, auditor, and validity.

2. Shared Responsibility

Security responsibilities vary:

• Microsoft secures its cloud platform according to its service model.
• elyXion secures systems and activities within its contracted control.
• Customers secure their users, business processes, data decisions, endpoints, approvals, and responsibilities retained in the service description.

The Order Form and architecture should make this allocation explicit.

3. Governance and Risk

elyXion intends to maintain security ownership, policies, asset and supplier awareness, risk assessment, exception handling, and periodic management review. Risks are prioritised by likelihood, impact, exposure, and service criticality.

4. Identity and Access

Controls may include:

• Microsoft Entra ID or another approved identity provider;
• Multi-factor authentication for privileged and remote access;
• Role-based access and least privilege;
• Separate privileged identities where proportionate;
• Conditional Access based on service and risk;
• Joiner, mover, leaver processes;
• Periodic access and service-principal review; and
• Time-bound or approval-based privileged access where available.

Customer tenant access should use delegated, auditable methods rather than shared credentials where technically possible.

5. Device and Workplace Security

elyXion -managed endpoints should use supported operating systems, encryption, screen lock, malware protection, patching, and central management appropriate to risk. Personnel must protect devices, report loss promptly, and avoid local storage of Customer Data unless needed and authorised.

6. Network and Infrastructure Security

Architecture may use segmentation, firewalls, security groups, private connectivity, restricted management interfaces, web application firewalls, DDoS protections, hardened images, and secure administrative paths. Actual controls depend on the hosted design.

7. Secure Delivery

Changes should be traceable, reviewed, tested, approved according to risk, and recoverable. Infrastructure as Code and CI/CD may improve repeatability. Secrets should use approved vaults and never be committed to source control. Production access and deployment rights should be restricted.

8. Vulnerability Management

elyXion intends to monitor relevant advisories, assess exposure, prioritise remediation, and track exceptions. Timelines depend on severity, exploitability, service criticality, vendor fixes, testing, and Customer approval. Unsupported systems may require compensating controls or retirement.

Independent penetration testing is not implied and should be commissioned according to risk and service maturity.

9. Logging and Monitoring

Security-relevant authentication, administrative action, service health, and application events may be logged. Access to logs is restricted. Retention and alerting vary by service. Monitoring does not guarantee detection of every event and is not 24/7 unless contracted.

10. Encryption and Secrets

elyXion uses supported encryption for data in transit and platform encryption at rest where available and appropriate. Highly sensitive keys, tokens, and credentials should be held in approved secret stores. Customer-managed keys are available only where designed and contracted.

11. Data Handling

Data should be minimised, classified where required, and kept in approved locations. Production data should not be used in development unless justified, protected, and authorised. Secure deletion follows provider capabilities, retention rules, and backup cycles.

12. Supplier Security

Supplier review considers service criticality, access, data types, contractual safeguards, incident obligations, data location, resilience, and exit. The Subprocessor List addresses providers processing Customer Personal Data.

13. Incident Response

The process covers reporting, triage, containment, eradication, recovery, evidence, communication, privacy assessment, and lessons learned. Customer notification depends on impact, contractual role, and available facts. The DPA governs Customer Personal Data breaches.

14. Resilience

Backups, redundancy, restoration, and continuity arrangements are service-specific. elyXion distinguishes successful backup jobs from verified recoverability. Recovery objectives apply only where stated and tested.

15. Personnel

Personnel are bound by confidentiality and receive role-relevant security instruction. Background screening, if required, must be specified by role, law, and customer contract; it is not universally claimed.

16. Customer Assurance

elyXion may respond to reasonable questionnaires and provide policies or evidence under confidentiality. It may withhold exploit details, credentials, other-customer information, or material whose disclosure creates risk.

17. Continuous Improvement

Controls evolve with threats, business growth, legal duties, incidents, architecture, and provider capabilities. Material changes to contracted safeguards follow the Agreement and DPA.