Information Security
How Axisonic governs the security of its people, processes, and technology — described as practice, not marketing.
1. Security Governance
Information security is governed as a defined program, not an afterthought:
- Information security policies — documented policies covering access, data handling, acceptable use, and incident response.
- Assigned security responsibility — a named lead accountable for the security program on every engagement.
- Policy reviews — policies are reviewed on a regular cycle and updated as threats and obligations change.
- Risk management — security risks are identified, assessed, and treated as part of project delivery and operations.
- Security awareness — staff receive security awareness training, including phishing and social engineering recognition.
Axisonic does not claim certifications — such as ISO/IEC 27001 or SOC 2 — unless and until they are independently verified and current. Where a client requires a specific certification or framework for an engagement, we will confirm our position in writing before contracting.
Axisonic follows security practices informed by the ACSC Essential Eight and other recognised frameworks — without claiming certification against them. Solutions can be designed to support customer environments with SOC 2-aligned or ISO 27001-aligned control requirements where the customer's assurance program requires it.
VIEW OUR ASSURANCE ROADMAP2. Identity and Access Management
- Multi-factor authentication — enforced for access to our systems and client environments where supported.
- Role-based access — access is granted according to role and engagement scope.
- Least privilege — users and services get the minimum access needed to do their work.
- Privileged account controls — administrative accounts are separated, individually attributable, and managed through vaults.
- Access reviews — access is reviewed periodically and revoked promptly when no longer required, including on staff departure.
3. Secure Software Development
- Peer reviews — code is reviewed by another engineer before it is merged.
- Dependency scanning — third-party libraries are scanned for known vulnerabilities and updated on a regular cycle.
- SAST — static application security testing is run against our codebases to catch flaws early.
- Secrets scanning — API keys and credentials are kept out of repositories and managed through secure vaults.
- Vulnerability management — identified vulnerabilities are tracked, triaged, and remediated against defined timelines. On selected enterprise engagements, penetration testing is coordinated on a regular schedule.
- CI/CD security — builds run automated checks, and production deployments are controlled and reviewed rather than ad hoc.
- Secure coding practices — including input validation, parameterised queries, and protection against common web vulnerabilities, informed by OWASP guidance. For AI systems we also apply prompt-injection and output screening controls.
4. Data Protection
- Encryption in transit — data is protected with TLS in transit.
- Encryption at rest — data is encrypted at rest using industry-standard algorithms such as AES-256.
- Key management — encryption keys are managed through cloud key management services (for example AWS KMS or GCP Key Management) with access controlled and audited.
- Environment separation — development, staging, and production environments are separated, and production data is never used for testing without authorisation.
- Backup protection — backups are encrypted and access-controlled so they cannot be a soft target.
5. Incident Response
We follow a defined incident response process so security events are handled quickly and consistently:
- Identification — incidents are detected and reported through monitoring, alerts, and staff.
- Escalation — incidents escalate to the accountable lead according to severity.
- Containment — affected systems are isolated to limit spread.
- Investigation — evidence is collected and the cause is established.
- Notification — clients are notified in line with contractual commitments, and where personal information is involved, in line with the Notifiable Data Breaches scheme.
- Recovery — systems are restored from verified backups.
- Post-incident review — we identify what went wrong and what changes prevent recurrence.
6. Business Continuity
- Backups — client systems are backed up on a defined schedule with verified restores.
- Disaster recovery — recovery plans exist for critical infrastructure we operate.
- Business continuity — continuity arrangements keep delivery and support running through disruptions.
- Recovery testing — recovery procedures are tested on a regular cycle rather than assumed to work.
7. Personnel Security
- Confidentiality agreements — team members are bound by confidentiality obligations.
- Security awareness training — ongoing training on secure handling of data and systems.
- Background checks — where applicable and permitted, verification checks are completed before staff access sensitive environments.
- Access termination procedures — access is revoked promptly when a person leaves an engagement or the business.
8. Supplier Security
Where subcontractors or suppliers are engaged to deliver part of our services, we assess and govern them before they touch client data:
- suppliers are assessed against security and data handling requirements before engagement;
- access is limited to what the supplier needs for the agreed scope;
- contractual obligations require suppliers to protect confidential and personal information; and
- Axisonic remains accountable to the client for all subcontracted work.