PYRON Trust Centre
CSA CAIQ answers
Every question of the Cloud Security Alliance's CAIQ v4.1, answered Yes, No or NA, with who owns it and a note.
Our answers to every question in the Cloud Security Alliance's Consensus Assessments Initiative Questionnaire (CAIQ), version 4.1.0, which goes with the Cloud Controls Matrix 4.1.1. They are our own self-assessment, checked against production on the date above, and have not been submitted to CSA's STAR Registry.
- The questions are CSA's, and its licence does not let us republish them. Each row names the question by its CAIQ identifier and the Cloud Controls Matrix control it belongs to; the questionnaire itself is free from cloudsecurityalliance.org.
- Each note starts with the answer. Yes means it is in place. No means it is partial or planned, and the note says what is in place and what is missing. NA means it does not apply, and says why.
- Responsibility is CSA's control ownership: Pyron (CSP-owned), or Shared where you have a part, which the note names.
Every answer is computed from the same control register as the other assessments here, so an answer here never disagrees with them. The Security overview and the policies give the detail.
- In place
- 131
- Partial
- 120
- Planned
- 31
- Not applicable
- 1
Showing 283 of 283
| Reference | Requirement | Status | Responsibility | How we meet it |
|---|---|---|---|---|
| A&A-01.1 | A&A-01 Audit and Assurance Policy and Procedures | Planned | Pyron | No. Pyron holds no security certification and has had no independent penetration test. |
| A&A-01.2 | A&A-01 Audit and Assurance Policy and Procedures | Planned | Pyron | No. Pyron holds no security certification and has had no independent penetration test. |
| A&A-02.1 | A&A-02 Independent Assessments | Planned | Pyron | No. Pyron holds no security certification and has had no independent penetration test. |
| A&A-03.1 | A&A-03 Risk Based Planning Assessment | Planned | Pyron | No. Pyron holds no security certification and has had no independent penetration test. |
| A&A-04.1 | A&A-04 Requirements Compliance | Planned | Pyron | No. Pyron holds no security certification and has had no independent penetration test. |
| A&A-05.1 | A&A-05 Audit Management Process | Planned | Pyron | No. Pyron holds no security certification and has had no independent penetration test. |
| A&A-06.1 | A&A-06 Remediation | In place | Pyron | Yes. Techly keeps a risk register: each risk's likelihood, impact, owner and treatment. The Technical Director reviews it every quarter, a gap in a control, an exception to a policy or a finding from a scan stays on it until it is closed, and only a director may accept a risk. |
| A&A-06.2 | A&A-06 Remediation | In place | Pyron | Yes. Techly keeps a risk register: each risk's likelihood, impact, owner and treatment. The Technical Director reviews it every quarter, a gap in a control, an exception to a policy or a finding from a scan stays on it until it is closed, and only a director may accept a risk. |
| AIS-01.1 | AIS-01 Application and Interface Security Policy and Procedures | In place | Pyron | Yes. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. |
| AIS-01.2 | AIS-01 Application and Interface Security Policy and Procedures | In place | Pyron | Yes. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. |
| AIS-02.1 | AIS-02 Application Security Baseline Requirements | In place | Pyron | Yes. Every change a person, an automation or the AI makes goes through the same path, which asks the permission engine before anything is written. What a person can see and do comes from their roles and from what is shared with them, and access to a place flows down to everything beneath it. Every operation in Pyron has a permission of its own, the permission engine's default answer is no, and only a role that holds the permission can add people, change roles or change the workspace's settings. |
| AIS-03.1 | AIS-03 Application Security Metrics | Planned | Pyron | No. Security metrics, such as incidents, vulnerabilities and the time to fix them, are not yet measured or reported. |
| AIS-04.1 | AIS-04 Secure Application Development Lifecycle | Partial | Pyron | No. Every change reaches production as a pull request, which merges only when its required checks pass: the test suites, a production build, an API contract check and a dependency scan. The team is small, and a second engineer's approval is not yet required. The owner's account can bypass these rules in an emergency, and GitHub records each bypass. Static analysis runs on every change, including security rules for our code, our container files and our build workflows. Automated tests that try to reach one workspace's data from another run on every change, as do censuses that hold every operation to its declared permission and every read to its scoping. |
| AIS-05.1 | AIS-05 Application Security Testing | Partial | Pyron | No. Every change reaches production as a pull request, which merges only when its required checks pass: the test suites, a production build, an API contract check and a dependency scan. The team is small, and a second engineer's approval is not yet required. The owner's account can bypass these rules in an emergency, and GitHub records each bypass. Automated tests that try to reach one workspace's data from another run on every change, as do censuses that hold every operation to its declared permission and every read to its scoping. |
| AIS-05.2 | AIS-05 Application Security Testing | Partial | Pyron | No. Automated tests that try to reach one workspace's data from another run on every change, as do censuses that hold every operation to its declared permission and every read to its scoping. Every change reaches production as a pull request, which merges only when its required checks pass: the test suites, a production build, an API contract check and a dependency scan. The team is small, and a second engineer's approval is not yet required. The owner's account can bypass these rules in an emergency, and GitHub records each bypass. |
| AIS-06.1 | AIS-06 Secure Application Deployment | In place | Pyron | Yes. Container images are built by our pipeline from base images pinned to an exact digest, with dependencies installed from lockfiles that pin each one's version and hash, scanned when they are pushed, and stored under tags that cannot be overwritten. Merging a change releases it to production automatically, as a recorded run tied to that change, with no manual deployment step. |
| AIS-06.2 | AIS-06 Secure Application Deployment | In place | Pyron | Yes. Merging a change releases it to production automatically, as a recorded run tied to that change, with no manual deployment step. |
| AIS-07.1 | AIS-07 Application Vulnerability Remediation | In place | Pyron | Yes. Every dependency is scanned for known vulnerabilities on each change and every day. A change that adds a high or critical advisory is blocked, and an accepted finding is recorded with its reason and an expiry, so it is looked at again. The Vulnerability Management Policy sets how fast a finding is fixed or accepted with a reason: a critical one within 7 days, a high one within 30, and others at the component's next update. One that is being exploited, or that exposes customer data, is an incident, handled at once. |
| AIS-07.2 | AIS-07 Application Vulnerability Remediation | In place | Pyron | Yes. Every dependency is scanned for known vulnerabilities on each change and every day. A change that adds a high or critical advisory is blocked, and an accepted finding is recorded with its reason and an expiry, so it is looked at again. Dependency updates are proposed automatically every week, once a release is 14 days old, as pull requests that pass the same checks as any change; an update that fixes a known advisory is proposed at once. Nothing merges by itself. |
| AIS-08.1 | AIS-08 API Security | In place | Pyron | Yes. Integrations and automations act as service accounts, each holding roles like a person. An API key belongs to one service account, is stored only as a hash, can expire and can be revoked at any time, and what is done with it is recorded on the audit trail as that account. A webhook with a signing secret is checked by its signature and its time, so an old one cannot be replayed. Cloudflare's managed firewall rules, including the OWASP Core Ruleset, run in front of Pyron, and requests to its API are rate-limited there. |
| AIS-08.2 | AIS-08 API Security | In place | Pyron | Yes. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. |
| BCR-01.1 | BCR-01 Business Continuity Management Policy and Procedures | In place | Pyron | Yes. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. |
| BCR-01.2 | BCR-01 Business Continuity Management Policy and Procedures | In place | Pyron | Yes. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. |
| BCR-02.1 | BCR-02 Risk Assessment and Impact Analysis | Partial | Pyron | No. Techly keeps a risk register: each risk's likelihood, impact, owner and treatment. The Technical Director reviews it every quarter, a gap in a control, an exception to a policy or a finding from a scan stays on it until it is closed, and only a director may accept a risk. The Business Continuity Policy sets out what is backed up, how a failure is handled and who leads recovery, with a recovery point of about five minutes and a restore test every quarter. The recovery time is unknown until the first restore test, which has not yet run, and the plan has not been exercised. |
| BCR-02.2 | BCR-02 Risk Assessment and Impact Analysis | Partial | Pyron | No. Techly keeps a risk register: each risk's likelihood, impact, owner and treatment. The Technical Director reviews it every quarter, a gap in a control, an exception to a policy or a finding from a scan stays on it until it is closed, and only a director may accept a risk. The Business Continuity Policy sets out what is backed up, how a failure is handled and who leads recovery, with a recovery point of about five minutes and a restore test every quarter. The recovery time is unknown until the first restore test, which has not yet run, and the plan has not been exercised. |
| BCR-03.1 | BCR-03 Business Continuity Strategy | Partial | Pyron | No. The application runs on servers in two availability zones, with the path that answers requests spread across both. The database is backed up continuously and can be restored to any moment in the last 35 days. It is protected from deletion, a final snapshot is taken if it is ever deleted, and an earlier version of a replaced or deleted file is kept for 30 days. The production database runs in a single availability zone, with no standby, and we make no uptime commitment. |
| BCR-04.1 | BCR-04 Business Continuity Planning | Partial | Pyron | No. The Business Continuity Policy sets out what is backed up, how a failure is handled and who leads recovery, with a recovery point of about five minutes and a restore test every quarter. The recovery time is unknown until the first restore test, which has not yet run, and the plan has not been exercised. |
| BCR-05.1 | BCR-05 Documentation | Partial | Pyron | No. Each operational alert has a written runbook saying what it means, what to check first and how to fix it, and how Pyron is provisioned, released and operated is written down beside its code. The Business Continuity Policy sets out what is backed up, how a failure is handled and who leads recovery, with a recovery point of about five minutes and a restore test every quarter. The recovery time is unknown until the first restore test, which has not yet run, and the plan has not been exercised. |
| BCR-05.2 | BCR-05 Documentation | Partial | Pyron | No. Each operational alert has a written runbook saying what it means, what to check first and how to fix it, and how Pyron is provisioned, released and operated is written down beside its code. The Business Continuity Policy sets out what is backed up, how a failure is handled and who leads recovery, with a recovery point of about five minutes and a restore test every quarter. The recovery time is unknown until the first restore test, which has not yet run, and the plan has not been exercised. |
| BCR-05.3 | BCR-05 Documentation | Partial | Pyron | No. Each operational alert has a written runbook saying what it means, what to check first and how to fix it, and how Pyron is provisioned, released and operated is written down beside its code. The Business Continuity Policy sets out what is backed up, how a failure is handled and who leads recovery, with a recovery point of about five minutes and a restore test every quarter. The recovery time is unknown until the first restore test, which has not yet run, and the plan has not been exercised. |
| BCR-06.1 | BCR-06 Business Continuity Exercises | Partial | Pyron | No. The Business Continuity Policy sets out what is backed up, how a failure is handled and who leads recovery, with a recovery point of about five minutes and a restore test every quarter. The recovery time is unknown until the first restore test, which has not yet run, and the plan has not been exercised. A full restore from backup has not yet been tested. The Business Continuity Policy schedules one every quarter. |
| BCR-07.1 | BCR-07 Communication | Partial | Pyron | No. We notify an affected customer of a suspected or confirmed security incident affecting their data without undue delay and no later than 48 hours, and assess a possible eligible data breach under the Privacy Act 1988 (Cth) within 30 days. Alerts that need someone page our on-call engineer through All Quiet. On-call is one engineer, with no second line. |
| BCR-08.1 | BCR-08 Backup | In place | Pyron | Yes. The database is backed up continuously and can be restored to any moment in the last 35 days. It is protected from deletion, a final snapshot is taken if it is ever deleted, and an earlier version of a replaced or deleted file is kept for 30 days. |
| BCR-08.2 | BCR-08 Backup | Partial | Pyron | No. The database is backed up continuously and can be restored to any moment in the last 35 days. It is protected from deletion, a final snapshot is taken if it is ever deleted, and an earlier version of a replaced or deleted file is kept for 30 days. The database, its backups and stored files are encrypted with AES-256 under keys held in AWS Key Management Service, which rotate automatically; the secrets behind authenticator apps are encrypted a second time inside the database. Backups are held in Melbourne only, in the same AWS account as production: there is no copy in a second region or account yet. |
| BCR-08.3 | BCR-08 Backup | Partial | Pyron | No. The database is backed up continuously and can be restored to any moment in the last 35 days. It is protected from deletion, a final snapshot is taken if it is ever deleted, and an earlier version of a replaced or deleted file is kept for 30 days. A full restore from backup has not yet been tested. The Business Continuity Policy schedules one every quarter. |
| BCR-09.1 | BCR-09 Disaster Response Plan | Partial | Pyron | No. The Business Continuity Policy sets out what is backed up, how a failure is handled and who leads recovery, with a recovery point of about five minutes and a restore test every quarter. The recovery time is unknown until the first restore test, which has not yet run, and the plan has not been exercised. |
| BCR-09.2 | BCR-09 Disaster Response Plan | Partial | Pyron | No. The Business Continuity Policy sets out what is backed up, how a failure is handled and who leads recovery, with a recovery point of about five minutes and a restore test every quarter. The recovery time is unknown until the first restore test, which has not yet run, and the plan has not been exercised. |
| BCR-10.1 | BCR-10 Response Plan Exercise | Partial | Pyron | No. The Business Continuity Policy sets out what is backed up, how a failure is handled and who leads recovery, with a recovery point of about five minutes and a restore test every quarter. The recovery time is unknown until the first restore test, which has not yet run, and the plan has not been exercised. A full restore from backup has not yet been tested. The Business Continuity Policy schedules one every quarter. |
| BCR-10.2 | BCR-10 Response Plan Exercise | Partial | Pyron | No. The Business Continuity Policy sets out what is backed up, how a failure is handled and who leads recovery, with a recovery point of about five minutes and a restore test every quarter. The recovery time is unknown until the first restore test, which has not yet run, and the plan has not been exercised. |
| BCR-11.1 | BCR-11 Equipment Redundancy | Partial | Pyron | No. The application runs on servers in two availability zones, with the path that answers requests spread across both. The production database runs in a single availability zone, with no standby, and we make no uptime commitment. Backups are held in Melbourne only, in the same AWS account as production: there is no copy in a second region or account yet. |
| CCC-01.1 | CCC-01 Change Management Policy and Procedures | In place | Pyron | Yes. The Change Management Policy sets out how every change to Pyron is made, checked, released and recorded, including emergency changes, and it is reviewed every year. |
| CCC-01.2 | CCC-01 Change Management Policy and Procedures | In place | Pyron | Yes. The Change Management Policy sets out how every change to Pyron is made, checked, released and recorded, including emergency changes, and it is reviewed every year. |
| CCC-02.1 | CCC-02 Quality Testing | Partial | Pyron | No. The Change Management Policy sets out how every change to Pyron is made, checked, released and recorded, including emergency changes, and it is reviewed every year. Every change reaches production as a pull request, which merges only when its required checks pass: the test suites, a production build, an API contract check and a dependency scan. The team is small, and a second engineer's approval is not yet required. The owner's account can bypass these rules in an emergency, and GitHub records each bypass. |
| CCC-03.1 | CCC-03 Change Management Technology | Partial | Pyron | No. Every change reaches production as a pull request, which merges only when its required checks pass: the test suites, a production build, an API contract check and a dependency scan. The team is small, and a second engineer's approval is not yet required. The owner's account can bypass these rules in an emergency, and GitHub records each bypass. |
| CCC-04.1 | CCC-04 Unauthorized Change Protection | In place | Pyron | Yes. Our cloud accounts, network edge and source control are defined in code, changed through pull requests, and scanned for insecure settings (Checkov) on every change. The Change Management Policy sets out how every change to Pyron is made, checked, released and recorded, including emergency changes, and it is reviewed every year. |
| CCC-05.1 | CCC-05 Change Agreements | Partial | Pyron | No. Techly's support engineers can sign in to any workspace to help, only through Techly's Google Workspace, which enforces 2-step verification, and a Support session lasts at most 8 hours and cannot be extended. What Support views and changes is recorded on the workspace's audit trail. A workspace cannot yet switch this access off. Every change in a workspace is recorded in plain words, whoever made it: a person, an automation, the AI or Support. What people view is recorded too, and so are attempts the permission engine refuses. The trail is kept for 24 months: records are only ever added, never edited, and each is cryptographically linked to the one before it, so tampering would be evident. |
| CCC-06.1 | CCC-06 Change Management Baseline | In place | Pyron | Yes. Our cloud accounts, network edge and source control are defined in code, changed through pull requests, and scanned for insecure settings (Checkov) on every change. A policy pack refuses an infrastructure change that would make storage public, grant unbounded permissions or remove the database's deletion protection, before it reaches AWS; and organisation policies keep our accounts to approved regions and stop anyone switching off their logging. |
| CCC-06.2 | CCC-06 Change Management Baseline | In place | Pyron | Yes. Our cloud accounts, network edge and source control are defined in code, changed through pull requests, and scanned for insecure settings (Checkov) on every change. The Change Management Policy sets out how every change to Pyron is made, checked, released and recorded, including emergency changes, and it is reviewed every year. |
| CCC-07.1 | CCC-07 Detection of Baseline Deviation | Partial | Pyron | No. Every night, each infrastructure stack is compared with its code, and a difference is fixed in code. AWS Config and AWS Security Hub, which would check our cloud settings against best practice continuously, are not switched on. |
| CCC-08.1 | CCC-08 Exception Management | In place | Pyron | Yes. The Change Management Policy sets out how every change to Pyron is made, checked, released and recorded, including emergency changes, and it is reviewed every year. |
| CCC-08.2 | CCC-08 Exception Management | In place | Pyron | Yes. The Change Management Policy sets out how every change to Pyron is made, checked, released and recorded, including emergency changes, and it is reviewed every year. Techly keeps a risk register: each risk's likelihood, impact, owner and treatment. The Technical Director reviews it every quarter, a gap in a control, an exception to a policy or a finding from a scan stays on it until it is closed, and only a director may accept a risk. |
| CCC-09.1 | CCC-09 Change Restoration | Partial | Pyron | No. Every change reaches production as a pull request, which merges only when its required checks pass: the test suites, a production build, an API contract check and a dependency scan. The team is small, and a second engineer's approval is not yet required. The owner's account can bypass these rules in an emergency, and GitHub records each bypass. A change that goes wrong is fixed by a new change: there is no rollback to an earlier state. |
| CEK-01.1 | CEK-01 Encryption and Key Management Policy and Procedures | In place | Pyron | Yes. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. |
| CEK-01.2 | CEK-01 Encryption and Key Management Policy and Procedures | In place | Pyron | Yes. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. |
| CEK-02.1 | CEK-02 CEK Roles and Responsibilities | In place | Pyron | Yes. Techly's two directors are accountable for information security. The Technical Director runs it day to day, and the Managing Director takes part in each policy's review and in every decision to accept a risk. Encryption keys are created and held in AWS Key Management Service, never exported, and rotate automatically, with a separate key for customer data, for stored logins and for signing. |
| CEK-03.1 | CEK-03 Data Protection | Partial | Pyron | No. The database, its backups and stored files are encrypted with AES-256 under keys held in AWS Key Management Service, which rotate automatically; the secrets behind authenticator apps are encrypted a second time inside the database. Pyron is served only over HTTPS with TLS 1.2 or later, and tells browsers never to use plain HTTP; the database refuses an unencrypted connection, and file storage refuses an unencrypted request. Traffic between our own services inside the cluster is not encrypted. |
| CEK-04.1 | CEK-04 Encryption Algorithm | Partial | Pyron | No. The database, its backups and stored files are encrypted with AES-256 under keys held in AWS Key Management Service, which rotate automatically; the secrets behind authenticator apps are encrypted a second time inside the database. Pyron is served only over HTTPS with TLS 1.2 or later, and tells browsers never to use plain HTTP; the database refuses an unencrypted connection, and file storage refuses an unencrypted request. Traffic between our own services inside the cluster is not encrypted. Information is classified Public, Internal, Confidential or Restricted, with handling rules for each. Everything a customer keeps in Pyron is Restricted: stored only in Pyron's production systems and with the providers our Privacy Statement names, and never copied to an email, a chat or a ticket. |
| CEK-05.1 | CEK-05 Encryption Change Management | Partial | Pyron | No. Every change reaches production as a pull request, which merges only when its required checks pass: the test suites, a production build, an API contract check and a dependency scan. The team is small, and a second engineer's approval is not yet required. The owner's account can bypass these rules in an emergency, and GitHub records each bypass. A key moves through AWS Key Management Service's own states, enabled, disabled and scheduled for deletion after a waiting period, and every change to a key is made in infrastructure code and recorded by AWS CloudTrail. The Cryptography Policy sets who holds the keys, and that a key suspected to be compromised is rotated and the data it protected re-encrypted. |
| CEK-06.1 | CEK-06 Encryption Change Cost Benefit Analysis | Partial | Pyron | No. Every change reaches production as a pull request, which merges only when its required checks pass: the test suites, a production build, an API contract check and a dependency scan. The team is small, and a second engineer's approval is not yet required. The owner's account can bypass these rules in an emergency, and GitHub records each bypass. Techly keeps a risk register: each risk's likelihood, impact, owner and treatment. The Technical Director reviews it every quarter, a gap in a control, an exception to a policy or a finding from a scan stays on it until it is closed, and only a director may accept a risk. |
| CEK-07.1 | CEK-07 Encryption Risk Management | In place | Pyron | Yes. Techly keeps a risk register: each risk's likelihood, impact, owner and treatment. The Technical Director reviews it every quarter, a gap in a control, an exception to a policy or a finding from a scan stays on it until it is closed, and only a director may accept a risk. Encryption keys are created and held in AWS Key Management Service, never exported, and rotate automatically, with a separate key for customer data, for stored logins and for signing. |
| CEK-08.1 | CEK-08 Service Customer Key Management Capability | Planned | Pyron | No. A customer cannot hold or revoke the keys that protect its own data: Pyron holds them. |
| CEK-09.1 | CEK-09 Encryption and Key Management Audit | Partial | Pyron | No. Activity on our AWS accounts is recorded by AWS CloudTrail into a separate archive account, where it is locked for 12 months. Pyron holds no security certification and has had no independent penetration test. |
| CEK-09.2 | CEK-09 Encryption and Key Management Audit | Partial | Pyron | No. Activity on our AWS accounts is recorded by AWS CloudTrail into a separate archive account, where it is locked for 12 months. Pyron holds no security certification and has had no independent penetration test. |
| CEK-10.1 | CEK-10 Key Generation | In place | Pyron | Yes. Encryption keys are created and held in AWS Key Management Service, never exported, and rotate automatically, with a separate key for customer data, for stored logins and for signing. |
| CEK-11.1 | CEK-11 Key Purpose | In place | Pyron | Yes. Encryption keys are created and held in AWS Key Management Service, never exported, and rotate automatically, with a separate key for customer data, for stored logins and for signing. |
| CEK-12.1 | CEK-12 Key Rotation | In place | Pyron | Yes. Encryption keys are created and held in AWS Key Management Service, never exported, and rotate automatically, with a separate key for customer data, for stored logins and for signing. |
| CEK-13.1 | CEK-13 Key Revocation | Partial | Pyron | No. A key moves through AWS Key Management Service's own states, enabled, disabled and scheduled for deletion after a waiting period, and every change to a key is made in infrastructure code and recorded by AWS CloudTrail. The Cryptography Policy sets who holds the keys, and that a key suspected to be compromised is rotated and the data it protected re-encrypted. The Incident Management Policy sets out how an incident is found, rated, contained, investigated with its evidence preserved, and learned from, who leads it and when customers are told. Each Critical or High incident gets a written review within 10 business days, and an affected customer may ask for a summary of it. The policy took effect on 25 October 2026, and the yearly walk-through of an incident scenario it requires has not yet been held. |
| CEK-14.1 | CEK-14 Key Destruction | In place | Pyron | Yes. A key moves through AWS Key Management Service's own states, enabled, disabled and scheduled for deletion after a waiting period, and every change to a key is made in infrastructure code and recorded by AWS CloudTrail. The Cryptography Policy sets who holds the keys, and that a key suspected to be compromised is rotated and the data it protected re-encrypted. |
| CEK-15.1 | CEK-15 Key Activation | In place | Pyron | Yes. A key moves through AWS Key Management Service's own states, enabled, disabled and scheduled for deletion after a waiting period, and every change to a key is made in infrastructure code and recorded by AWS CloudTrail. The Cryptography Policy sets who holds the keys, and that a key suspected to be compromised is rotated and the data it protected re-encrypted. |
| CEK-16.1 | CEK-16 Key Suspension | In place | Pyron | Yes. A key moves through AWS Key Management Service's own states, enabled, disabled and scheduled for deletion after a waiting period, and every change to a key is made in infrastructure code and recorded by AWS CloudTrail. The Cryptography Policy sets who holds the keys, and that a key suspected to be compromised is rotated and the data it protected re-encrypted. |
| CEK-17.1 | CEK-17 Key Deactivation | In place | Pyron | Yes. A key moves through AWS Key Management Service's own states, enabled, disabled and scheduled for deletion after a waiting period, and every change to a key is made in infrastructure code and recorded by AWS CloudTrail. The Cryptography Policy sets who holds the keys, and that a key suspected to be compromised is rotated and the data it protected re-encrypted. |
| CEK-18.1 | CEK-18 Key Archival | In place | Pyron | Yes. A key moves through AWS Key Management Service's own states, enabled, disabled and scheduled for deletion after a waiting period, and every change to a key is made in infrastructure code and recorded by AWS CloudTrail. The Cryptography Policy sets who holds the keys, and that a key suspected to be compromised is rotated and the data it protected re-encrypted. |
| CEK-19.1 | CEK-19 Key Compromise | In place | Pyron | Yes. A key moves through AWS Key Management Service's own states, enabled, disabled and scheduled for deletion after a waiting period, and every change to a key is made in infrastructure code and recorded by AWS CloudTrail. The Cryptography Policy sets who holds the keys, and that a key suspected to be compromised is rotated and the data it protected re-encrypted. |
| CEK-20.1 | CEK-20 Key Recovery | In place | Pyron | Yes. A key moves through AWS Key Management Service's own states, enabled, disabled and scheduled for deletion after a waiting period, and every change to a key is made in infrastructure code and recorded by AWS CloudTrail. The Cryptography Policy sets who holds the keys, and that a key suspected to be compromised is rotated and the data it protected re-encrypted. Techly keeps a risk register: each risk's likelihood, impact, owner and treatment. The Technical Director reviews it every quarter, a gap in a control, an exception to a policy or a finding from a scan stays on it until it is closed, and only a director may accept a risk. |
| CEK-21.1 | CEK-21 Key Inventory Management | In place | Pyron | Yes. A key moves through AWS Key Management Service's own states, enabled, disabled and scheduled for deletion after a waiting period, and every change to a key is made in infrastructure code and recorded by AWS CloudTrail. The Cryptography Policy sets who holds the keys, and that a key suspected to be compromised is rotated and the data it protected re-encrypted. Activity on our AWS accounts is recorded by AWS CloudTrail into a separate archive account, where it is locked for 12 months. |
| DCS-01.1 | DCS-01 Physical and Environmental Security Policy and Procedures | Partial | Pyron | No. Pyron runs on AWS and Cloudflare, with no data centre or server room of its own. The physical and environmental security of the facilities it runs in, including their power, cooling, cabling and the disposal of their storage media, is theirs, under their own independent certifications. A device used for Techly work must have its disk encrypted, a screen lock that engages within a few minutes, and a supported operating system kept up to date (Acceptable Use Policy). Each person confirms this when they join and every year; nothing enforces it centrally. |
| DCS-01.2 | DCS-01 Physical and Environmental Security Policy and Procedures | Partial | Pyron | No. Pyron runs on AWS and Cloudflare, with no data centre or server room of its own. The physical and environmental security of the facilities it runs in, including their power, cooling, cabling and the disposal of their storage media, is theirs, under their own independent certifications. A device used for Techly work must have its disk encrypted, a screen lock that engages within a few minutes, and a supported operating system kept up to date (Acceptable Use Policy). Each person confirms this when they join and every year; nothing enforces it centrally. |
| DCS-02.1 | DCS-02 Off-Site Equipment Disposal Policy and Procedures | Planned | Pyron | No. The devices staff use are not managed centrally: there is no inventory, enforcement or remote wipe of them. |
| DCS-02.2 | DCS-02 Off-Site Equipment Disposal Policy and Procedures | Partial | Pyron | No. Pyron runs on AWS and Cloudflare, with no data centre or server room of its own. The physical and environmental security of the facilities it runs in, including their power, cooling, cabling and the disposal of their storage media, is theirs, under their own independent certifications. A device used for Techly work must have its disk encrypted, a screen lock that engages within a few minutes, and a supported operating system kept up to date (Acceptable Use Policy). Each person confirms this when they join and every year; nothing enforces it centrally. |
| DCS-02.3 | DCS-02 Off-Site Equipment Disposal Policy and Procedures | Planned | Pyron | No. The devices staff use are not managed centrally: there is no inventory, enforcement or remote wipe of them. |
| DCS-03.1 | DCS-03 Off-Site Transfer Authorization Policy and Procedures | In place | Pyron | Yes. Information is classified Public, Internal, Confidential or Restricted, with handling rules for each. Everything a customer keeps in Pyron is Restricted: stored only in Pyron's production systems and with the providers our Privacy Statement names, and never copied to an email, a chat or a ticket. Pyron runs on AWS and Cloudflare, with no data centre or server room of its own. The physical and environmental security of the facilities it runs in, including their power, cooling, cabling and the disposal of their storage media, is theirs, under their own independent certifications. |
| DCS-03.2 | DCS-03 Off-Site Transfer Authorization Policy and Procedures | Partial | Pyron | No. Our cloud accounts, network edge and source control are defined in code, changed through pull requests, and scanned for insecure settings (Checkov) on every change. Every change reaches production as a pull request, which merges only when its required checks pass: the test suites, a production build, an API contract check and a dependency scan. The team is small, and a second engineer's approval is not yet required. The owner's account can bypass these rules in an emergency, and GitHub records each bypass. |
| DCS-03.3 | DCS-03 Off-Site Transfer Authorization Policy and Procedures | In place | Pyron | Yes. Information is classified Public, Internal, Confidential or Restricted, with handling rules for each. Everything a customer keeps in Pyron is Restricted: stored only in Pyron's production systems and with the providers our Privacy Statement names, and never copied to an email, a chat or a ticket. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. |
| DCS-04.1 | DCS-04 Secure Area Policy and Procedures | Partial | Pyron | No. Pyron runs on AWS and Cloudflare, with no data centre or server room of its own. The physical and environmental security of the facilities it runs in, including their power, cooling, cabling and the disposal of their storage media, is theirs, under their own independent certifications. A device used for Techly work must have its disk encrypted, a screen lock that engages within a few minutes, and a supported operating system kept up to date (Acceptable Use Policy). Each person confirms this when they join and every year; nothing enforces it centrally. |
| DCS-04.2 | DCS-04 Secure Area Policy and Procedures | Partial | Pyron | No. Pyron runs on AWS and Cloudflare, with no data centre or server room of its own. The physical and environmental security of the facilities it runs in, including their power, cooling, cabling and the disposal of their storage media, is theirs, under their own independent certifications. A device used for Techly work must have its disk encrypted, a screen lock that engages within a few minutes, and a supported operating system kept up to date (Acceptable Use Policy). Each person confirms this when they join and every year; nothing enforces it centrally. |
| DCS-05.1 | DCS-05 Secure Media Transportation Policy and Procedures | In place | Pyron | Yes. Pyron runs on AWS and Cloudflare, with no data centre or server room of its own. The physical and environmental security of the facilities it runs in, including their power, cooling, cabling and the disposal of their storage media, is theirs, under their own independent certifications. Information is classified Public, Internal, Confidential or Restricted, with handling rules for each. Everything a customer keeps in Pyron is Restricted: stored only in Pyron's production systems and with the providers our Privacy Statement names, and never copied to an email, a chat or a ticket. |
| DCS-05.2 | DCS-05 Secure Media Transportation Policy and Procedures | In place | Pyron | Yes. Pyron runs on AWS and Cloudflare, with no data centre or server room of its own. The physical and environmental security of the facilities it runs in, including their power, cooling, cabling and the disposal of their storage media, is theirs, under their own independent certifications. Information is classified Public, Internal, Confidential or Restricted, with handling rules for each. Everything a customer keeps in Pyron is Restricted: stored only in Pyron's production systems and with the providers our Privacy Statement names, and never copied to an email, a chat or a ticket. |
| DCS-06.1 | DCS-06 Assets Classification | In place | Pyron | Yes. Information is classified Public, Internal, Confidential or Restricted, with handling rules for each. Everything a customer keeps in Pyron is Restricted: stored only in Pyron's production systems and with the providers our Privacy Statement names, and never copied to an email, a chat or a ticket. Our cloud accounts, network edge and source control are defined in code, changed through pull requests, and scanned for insecure settings (Checkov) on every change. |
| DCS-06.2 | DCS-06 Assets Classification | In place | Pyron | Yes. Information is classified Public, Internal, Confidential or Restricted, with handling rules for each. Everything a customer keeps in Pyron is Restricted: stored only in Pyron's production systems and with the providers our Privacy Statement names, and never copied to an email, a chat or a ticket. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. |
| DCS-07.1 | DCS-07 Assets Cataloguing and Tracking | In place | Pyron | Yes. Our cloud accounts, network edge and source control are defined in code, changed through pull requests, and scanned for insecure settings (Checkov) on every change. |
| DCS-07.2 | DCS-07 Assets Cataloguing and Tracking | In place | Pyron | Yes. Our cloud accounts, network edge and source control are defined in code, changed through pull requests, and scanned for insecure settings (Checkov) on every change. Every night, each infrastructure stack is compared with its code, and a difference is fixed in code. |
| DCS-08.1 | DCS-08 Controlled Physical Access Points | In place | Pyron | Yes. Pyron runs on AWS and Cloudflare, with no data centre or server room of its own. The physical and environmental security of the facilities it runs in, including their power, cooling, cabling and the disposal of their storage media, is theirs, under their own independent certifications. |
| DCS-09.1 | DCS-09 Equipment Identification | Not applicable | Pyron | NA. Pyron has no equipment of its own to identify: a connection is authenticated by the identity making it, never by a device. |
| DCS-10.1 | DCS-10 Secure Area Authorization | In place | Pyron | Yes. Pyron runs on AWS and Cloudflare, with no data centre or server room of its own. The physical and environmental security of the facilities it runs in, including their power, cooling, cabling and the disposal of their storage media, is theirs, under their own independent certifications. |
| DCS-10.2 | DCS-10 Secure Area Authorization | In place | Pyron | Yes. Pyron runs on AWS and Cloudflare, with no data centre or server room of its own. The physical and environmental security of the facilities it runs in, including their power, cooling, cabling and the disposal of their storage media, is theirs, under their own independent certifications. |
| DCS-11.1 | DCS-11 Surveillance System | In place | Pyron | Yes. Pyron runs on AWS and Cloudflare, with no data centre or server room of its own. The physical and environmental security of the facilities it runs in, including their power, cooling, cabling and the disposal of their storage media, is theirs, under their own independent certifications. |
| DCS-12.1 | DCS-12 Adverse Event Response Training | In place | Pyron | Yes. Pyron runs on AWS and Cloudflare, with no data centre or server room of its own. The physical and environmental security of the facilities it runs in, including their power, cooling, cabling and the disposal of their storage media, is theirs, under their own independent certifications. |
| DCS-13.1 | DCS-13 Cabling Security | In place | Pyron | Yes. Pyron runs on AWS and Cloudflare, with no data centre or server room of its own. The physical and environmental security of the facilities it runs in, including their power, cooling, cabling and the disposal of their storage media, is theirs, under their own independent certifications. |
| DCS-14.1 | DCS-14 Environmental Systems | In place | Pyron | Yes. Pyron runs on AWS and Cloudflare, with no data centre or server room of its own. The physical and environmental security of the facilities it runs in, including their power, cooling, cabling and the disposal of their storage media, is theirs, under their own independent certifications. |
| DCS-15.1 | DCS-15 Secure Utilities | In place | Pyron | Yes. Pyron runs on AWS and Cloudflare, with no data centre or server room of its own. The physical and environmental security of the facilities it runs in, including their power, cooling, cabling and the disposal of their storage media, is theirs, under their own independent certifications. |
| DCS-16.1 | DCS-16 Equipment Location | In place | Pyron | Yes. Pyron runs on AWS and Cloudflare, with no data centre or server room of its own. The physical and environmental security of the facilities it runs in, including their power, cooling, cabling and the disposal of their storage media, is theirs, under their own independent certifications. |
| DCS-17.1 | DCS-17 Datacenter Metrics | In place | Pyron | Yes. Pyron runs on AWS and Cloudflare, with no data centre or server room of its own. The physical and environmental security of the facilities it runs in, including their power, cooling, cabling and the disposal of their storage media, is theirs, under their own independent certifications. |
| DCS-18.1 | DCS-18 Datacenter Operations Resilience | Partial | Pyron | No. The application runs on servers in two availability zones, with the path that answers requests spread across both. The production database runs in a single availability zone, with no standby, and we make no uptime commitment. The database is backed up continuously and can be restored to any moment in the last 35 days. It is protected from deletion, a final snapshot is taken if it is ever deleted, and an earlier version of a replaced or deleted file is kept for 30 days. |
| DSP-01.1 | DSP-01 Security and Privacy Policy and Procedures | In place | Pyron | Yes. Information is classified Public, Internal, Confidential or Restricted, with handling rules for each. Everything a customer keeps in Pyron is Restricted: stored only in Pyron's production systems and with the providers our Privacy Statement names, and never copied to an email, a chat or a ticket. The Records Management Policy sets how long each kind of record is kept, and how a workspace's data is deleted when its subscription ends. Personal information is handled as our Privacy Statement and the Data Protection and Privacy Policy set out, under the Privacy Act 1988 (Cth), and a Data Protection Officer is accountable for it. |
| DSP-01.2 | DSP-01 Security and Privacy Policy and Procedures | In place | Pyron | Yes. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. |
| DSP-02.1 | DSP-02 Secure Disposal | In place | Pyron | Yes. Pyron runs on AWS and Cloudflare, with no data centre or server room of its own. The physical and environmental security of the facilities it runs in, including their power, cooling, cabling and the disposal of their storage media, is theirs, under their own independent certifications. People can export a table's records as a spreadsheet. When a subscription ends there is a 30-day export window, then deletion within 90 days; deleting a workspace removes its database schema, its files, its stored secrets and its single sign-on connection, and backups age out on their normal rotation. |
| DSP-03.1 | DSP-03 Data Inventory | In place | Pyron | Yes. Information is classified Public, Internal, Confidential or Restricted, with handling rules for each. Everything a customer keeps in Pyron is Restricted: stored only in Pyron's production systems and with the providers our Privacy Statement names, and never copied to an email, a chat or a ticket. Every service provider that handles customer data is named on Data locations and in our Privacy Statement, with what it receives and where, and a change to that list is recorded in the statement's revision history. |
| DSP-03.2 | DSP-03 Data Inventory | In place | Pyron | Yes. Every service provider that handles customer data is named on Data locations and in our Privacy Statement, with what it receives and where, and a change to that list is recorded in the statement's revision history. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. |
| DSP-04.1 | DSP-04 Data Classification | In place | Shared | Yes. Information is classified Public, Internal, Confidential or Restricted, with handling rules for each. Everything a customer keeps in Pyron is Restricted: stored only in Pyron's production systems and with the providers our Privacy Statement names, and never copied to an email, a chat or a ticket. Your part: classify what you keep in Pyron as your own rules require; Pyron treats all of it as Restricted. |
| DSP-05.1 | DSP-05 Data Flow Documentation | In place | Pyron | Yes. Every service provider that handles customer data is named on Data locations and in our Privacy Statement, with what it receives and where, and a change to that list is recorded in the statement's revision history. Your records and files are stored in Australia, and the AI runs in Australia: Pyron's services may call only Amazon Bedrock's Australian models. |
| DSP-05.2 | DSP-05 Data Flow Documentation | In place | Pyron | Yes. Every service provider that handles customer data is named on Data locations and in our Privacy Statement, with what it receives and where, and a change to that list is recorded in the statement's revision history. |
| DSP-06.1 | DSP-06 Data Ownership and Stewardship | In place | Pyron | Yes. Personal information is handled as our Privacy Statement and the Data Protection and Privacy Policy set out, under the Privacy Act 1988 (Cth), and a Data Protection Officer is accountable for it. Information is classified Public, Internal, Confidential or Restricted, with handling rules for each. Everything a customer keeps in Pyron is Restricted: stored only in Pyron's production systems and with the providers our Privacy Statement names, and never copied to an email, a chat or a ticket. |
| DSP-06.2 | DSP-06 Data Ownership and Stewardship | In place | Pyron | Yes. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. |
| DSP-07.1 | DSP-07 Data Protection by Design and Default | In place | Pyron | Yes. Each workspace's data lives in a database schema of its own, and every request is answered inside the schema of the workspace it was made to. Each workspace has its own environment in our authorisation service, and a sign-in names the workspace it was issued for, so no other workspace accepts it. The database server and the computing cluster are shared. Every change a person, an automation or the AI makes goes through the same path, which asks the permission engine before anything is written. What a person can see and do comes from their roles and from what is shared with them, and access to a place flows down to everything beneath it. Every operation in Pyron has a permission of its own, the permission engine's default answer is no, and only a role that holds the permission can add people, change roles or change the workspace's settings. |
| DSP-08.1 | DSP-08 Data Privacy by Design and Default | In place | Pyron | Yes. Personal information is handled as our Privacy Statement and the Data Protection and Privacy Policy set out, under the Privacy Act 1988 (Cth), and a Data Protection Officer is accountable for it. Your records and files are stored in Australia, and the AI runs in Australia: Pyron's services may call only Amazon Bedrock's Australian models. |
| DSP-08.2 | DSP-08 Data Privacy by Design and Default | In place | Pyron | Yes. What a person can see and do comes from their roles and from what is shared with them, and access to a place flows down to everything beneath it. Every operation in Pyron has a permission of its own, the permission engine's default answer is no, and only a role that holds the permission can add people, change roles or change the workspace's settings. |
| DSP-09.1 | DSP-09 Data Protection Impact Assessment | Planned | Pyron | No. Privacy impact assessments are not yet documented. |
| DSP-10.1 | DSP-10 Sensitive Data Transfer | Partial | Pyron | No. Pyron is served only over HTTPS with TLS 1.2 or later, and tells browsers never to use plain HTTP; the database refuses an unencrypted connection, and file storage refuses an unencrypted request. Traffic between our own services inside the cluster is not encrypted. Every service provider that handles customer data is named on Data locations and in our Privacy Statement, with what it receives and where, and a change to that list is recorded in the statement's revision history. Personal information is handled as our Privacy Statement and the Data Protection and Privacy Policy set out, under the Privacy Act 1988 (Cth), and a Data Protection Officer is accountable for it. |
| DSP-11.1 | DSP-11 Personal Data Access, Reversal, Rectification and Deletion | In place | Shared | Yes. A request to access or correct personal information we hold is acknowledged within 5 business days and answered within 30. Where the information sits in a customer's workspace, we help the customer answer it. Your part: answer requests about the personal information in your workspace; we help. |
| DSP-12.1 | DSP-12 Limitation of Purpose in Personal Data Processing | In place | Pyron | Yes. Personal information is handled as our Privacy Statement and the Data Protection and Privacy Policy set out, under the Privacy Act 1988 (Cth), and a Data Protection Officer is accountable for it. |
| DSP-13.1 | DSP-13 Personal Data Sub-processing | Partial | Pyron | No. Every service provider that handles customer data is named on Data locations and in our Privacy Statement, with what it receives and where, and a change to that list is recorded in the statement's revision history. The Supplier Security Policy sets how a provider is chosen (what it will receive and where, its security, its data processing terms, and how we would leave it) and has each one reviewed every year. Copies of each provider's data processing terms are still being collected. |
| DSP-14.1 | DSP-14 Disclosure of Data Sub-processors | In place | Pyron | Yes. Every service provider that handles customer data is named on Data locations and in our Privacy Statement, with what it receives and where, and a change to that list is recorded in the statement's revision history. |
| DSP-15.1 | DSP-15 Limitation of Production Data Use | Partial | Pyron | No. Automated tests run on generated data. A database migration that rewrites rows is rehearsed on a copy of production restored inside our AWS account, which only the rehearsal can reach, and moving a workspace from Techly's earlier platform runs on a working copy that is deleted once the move is checked. Customers are not asked before a migration is rehearsed on a copy of production. |
| DSP-16.1 | DSP-16 Data Retention and Deletion | In place | Shared | Yes. The Records Management Policy sets how long each kind of record is kept, and how a workspace's data is deleted when its subscription ends. People can export a table's records as a spreadsheet. When a subscription ends there is a 30-day export window, then deletion within 90 days; deleting a workspace removes its database schema, its files, its stored secrets and its single sign-on connection, and backups age out on their normal rotation. Your part: decide how long the records you keep in Pyron are kept. |
| DSP-17.1 | DSP-17 Sensitive Data Protection | In place | Pyron | Yes. Information is classified Public, Internal, Confidential or Restricted, with handling rules for each. Everything a customer keeps in Pyron is Restricted: stored only in Pyron's production systems and with the providers our Privacy Statement names, and never copied to an email, a chat or a ticket. The database, its backups and stored files are encrypted with AES-256 under keys held in AWS Key Management Service, which rotate automatically; the secrets behind authenticator apps are encrypted a second time inside the database. |
| DSP-18.1 | DSP-18 Disclosure Notification | Partial | Pyron | No. The Privacy Statement says we disclose personal information only where the law requires or authorises it, or to a law enforcement or regulatory body acting within its powers. How we handle such a request, and when we tell the customer, is not yet published. |
| DSP-19.1 | DSP-19 Data Location | In place | Pyron | Yes. Your records and files are stored in Australia, and the AI runs in Australia: Pyron's services may call only Amazon Bedrock's Australian models. Every service provider that handles customer data is named on Data locations and in our Privacy Statement, with what it receives and where, and a change to that list is recorded in the statement's revision history. |
| GRC-01.1 | GRC-01 Governance Program Policy and Procedures | In place | Pyron | Yes. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. Techly's two directors are accountable for information security. The Technical Director runs it day to day, and the Managing Director takes part in each policy's review and in every decision to accept a risk. |
| GRC-01.2 | GRC-01 Governance Program Policy and Procedures | In place | Pyron | Yes. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. |
| GRC-02.1 | GRC-02 Risk Management Program | In place | Pyron | Yes. Techly keeps a risk register: each risk's likelihood, impact, owner and treatment. The Technical Director reviews it every quarter, a gap in a control, an exception to a policy or a finding from a scan stays on it until it is closed, and only a director may accept a risk. |
| GRC-03.1 | GRC-03 Organizational Policy Reviews | In place | Pyron | Yes. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. |
| GRC-04.1 | GRC-04 Policy Exception Process | In place | Pyron | Yes. Techly keeps a risk register: each risk's likelihood, impact, owner and treatment. The Technical Director reviews it every quarter, a gap in a control, an exception to a policy or a finding from a scan stays on it until it is closed, and only a director may accept a risk. |
| GRC-05.1 | GRC-05 Information Security Program | In place | Pyron | Yes. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. This Trust Centre publishes our security overview, where each kind of data is held and these self-assessments, openly and each with a version and a date. |
| GRC-06.1 | GRC-06 Governance Responsibility Model | In place | Pyron | Yes. Techly's two directors are accountable for information security. The Technical Director runs it day to day, and the Managing Director takes part in each policy's review and in every decision to accept a risk. |
| GRC-07.1 | GRC-07 Information System Regulatory Mapping | Partial | Pyron | No. Personal information is handled as our Privacy Statement and the Data Protection and Privacy Policy set out, under the Privacy Act 1988 (Cth), and a Data Protection Officer is accountable for it. Requirements beyond privacy law are not yet listed in one register. |
| GRC-07.2 | GRC-07 Information System Regulatory Mapping | In place | Pyron | Yes. Personal information is handled as our Privacy Statement and the Data Protection and Privacy Policy set out, under the Privacy Act 1988 (Cth), and a Data Protection Officer is accountable for it. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. |
| GRC-08.1 | GRC-08 Special Interest Groups | Partial | Pyron | No. Threat intelligence reaches us through the services that carry it: new advisories for our dependencies every day, the threat categories our outbound filter blocks, and Cloudflare's managed firewall rules. Gathering it as a process of its own, including membership of security forums, is not yet documented. |
| HRS-01.1 | HRS-01 Background Screening Policy and Procedures | Planned | Pyron | No. Screening before someone joins, and the security terms of employment and confidentiality agreements, are not yet documented in a policy. |
| HRS-01.2 | HRS-01 Background Screening Policy and Procedures | Planned | Pyron | No. Screening before someone joins, and the security terms of employment and confidentiality agreements, are not yet documented in a policy. |
| HRS-01.3 | HRS-01 Background Screening Policy and Procedures | Planned | Pyron | No. Screening before someone joins, and the security terms of employment and confidentiality agreements, are not yet documented in a policy. |
| HRS-02.1 | HRS-02 Acceptable Use of Technology Policy and Procedures | Partial | Pyron | No. Staff read Techly's policies when they join and confirm each year that they follow them, use their own named account with two-step sign-in wherever a system offers it, report anything that may be an incident straight away, and lose their access on the day they leave; a breach of the policies can lead to access being removed. Security training beyond the policies is not yet documented. Information is classified Public, Internal, Confidential or Restricted, with handling rules for each. Everything a customer keeps in Pyron is Restricted: stored only in Pyron's production systems and with the providers our Privacy Statement names, and never copied to an email, a chat or a ticket. |
| HRS-02.2 | HRS-02 Acceptable Use of Technology Policy and Procedures | Partial | Pyron | No. Staff read Techly's policies when they join and confirm each year that they follow them, use their own named account with two-step sign-in wherever a system offers it, report anything that may be an incident straight away, and lose their access on the day they leave; a breach of the policies can lead to access being removed. Security training beyond the policies is not yet documented. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. |
| HRS-03.1 | HRS-03 Clean Desk Policy and Procedures | Partial | Pyron | No. A device used for Techly work must have its disk encrypted, a screen lock that engages within a few minutes, and a supported operating system kept up to date (Acceptable Use Policy). Each person confirms this when they join and every year; nothing enforces it centrally. |
| HRS-03.2 | HRS-03 Clean Desk Policy and Procedures | Partial | Pyron | No. A device used for Techly work must have its disk encrypted, a screen lock that engages within a few minutes, and a supported operating system kept up to date (Acceptable Use Policy). Each person confirms this when they join and every year; nothing enforces it centrally. |
| HRS-04.1 | HRS-04 Remote and Home Working Policy and Procedures | Partial | Pyron | No. A device used for Techly work must have its disk encrypted, a screen lock that engages within a few minutes, and a supported operating system kept up to date (Acceptable Use Policy). Each person confirms this when they join and every year; nothing enforces it centrally. Information is classified Public, Internal, Confidential or Restricted, with handling rules for each. Everything a customer keeps in Pyron is Restricted: stored only in Pyron's production systems and with the providers our Privacy Statement names, and never copied to an email, a chat or a ticket. |
| HRS-04.2 | HRS-04 Remote and Home Working Policy and Procedures | Partial | Pyron | No. A device used for Techly work must have its disk encrypted, a screen lock that engages within a few minutes, and a supported operating system kept up to date (Acceptable Use Policy). Each person confirms this when they join and every year; nothing enforces it centrally. Information is classified Public, Internal, Confidential or Restricted, with handling rules for each. Everything a customer keeps in Pyron is Restricted: stored only in Pyron's production systems and with the providers our Privacy Statement names, and never copied to an email, a chat or a ticket. |
| HRS-05.1 | HRS-05 Asset returns | Partial | Pyron | No. Staff read Techly's policies when they join and confirm each year that they follow them, use their own named account with two-step sign-in wherever a system offers it, report anything that may be an incident straight away, and lose their access on the day they leave; a breach of the policies can lead to access being removed. Security training beyond the policies is not yet documented. The devices staff use are not managed centrally: there is no inventory, enforcement or remote wipe of them. |
| HRS-06.1 | HRS-06 Employment Termination | Partial | Pyron | No. Staff read Techly's policies when they join and confirm each year that they follow them, use their own named account with two-step sign-in wherever a system offers it, report anything that may be an incident straight away, and lose their access on the day they leave; a breach of the policies can lead to access being removed. Security training beyond the policies is not yet documented. |
| HRS-07.1 | HRS-07 Employment Agreement Process | Planned | Pyron | No. Screening before someone joins, and the security terms of employment and confidentiality agreements, are not yet documented in a policy. |
| HRS-08.1 | HRS-08 Employment Agreement Content | Partial | Pyron | No. Screening before someone joins, and the security terms of employment and confidentiality agreements, are not yet documented in a policy. Staff read Techly's policies when they join and confirm each year that they follow them, use their own named account with two-step sign-in wherever a system offers it, report anything that may be an incident straight away, and lose their access on the day they leave; a breach of the policies can lead to access being removed. Security training beyond the policies is not yet documented. |
| HRS-09.1 | HRS-09 Personnel Roles and Responsibilities | Partial | Pyron | No. Techly's two directors are accountable for information security. The Technical Director runs it day to day, and the Managing Director takes part in each policy's review and in every decision to accept a risk. Staff read Techly's policies when they join and confirm each year that they follow them, use their own named account with two-step sign-in wherever a system offers it, report anything that may be an incident straight away, and lose their access on the day they leave; a breach of the policies can lead to access being removed. Security training beyond the policies is not yet documented. |
| HRS-10.1 | HRS-10 Non-Disclosure Agreements | Planned | Pyron | No. Screening before someone joins, and the security terms of employment and confidentiality agreements, are not yet documented in a policy. |
| HRS-11.1 | HRS-11 Security Awareness Training | Partial | Pyron | No. Staff read Techly's policies when they join and confirm each year that they follow them, use their own named account with two-step sign-in wherever a system offers it, report anything that may be an incident straight away, and lose their access on the day they leave; a breach of the policies can lead to access being removed. Security training beyond the policies is not yet documented. |
| HRS-11.2 | HRS-11 Security Awareness Training | Partial | Pyron | No. Staff read Techly's policies when they join and confirm each year that they follow them, use their own named account with two-step sign-in wherever a system offers it, report anything that may be an incident straight away, and lose their access on the day they leave; a breach of the policies can lead to access being removed. Security training beyond the policies is not yet documented. |
| HRS-12.1 | HRS-12 Personal and Sensitive Data Awareness and Training | Partial | Pyron | No. Staff read Techly's policies when they join and confirm each year that they follow them, use their own named account with two-step sign-in wherever a system offers it, report anything that may be an incident straight away, and lose their access on the day they leave; a breach of the policies can lead to access being removed. Security training beyond the policies is not yet documented. Information is classified Public, Internal, Confidential or Restricted, with handling rules for each. Everything a customer keeps in Pyron is Restricted: stored only in Pyron's production systems and with the providers our Privacy Statement names, and never copied to an email, a chat or a ticket. |
| HRS-12.2 | HRS-12 Personal and Sensitive Data Awareness and Training | Partial | Pyron | No. Staff read Techly's policies when they join and confirm each year that they follow them, use their own named account with two-step sign-in wherever a system offers it, report anything that may be an incident straight away, and lose their access on the day they leave; a breach of the policies can lead to access being removed. Security training beyond the policies is not yet documented. |
| HRS-13.1 | HRS-13 Compliance User Responsibility | Partial | Pyron | No. Staff read Techly's policies when they join and confirm each year that they follow them, use their own named account with two-step sign-in wherever a system offers it, report anything that may be an incident straight away, and lose their access on the day they leave; a breach of the policies can lead to access being removed. Security training beyond the policies is not yet documented. |
| IAM-01.1 | IAM-01 Identity and Access Management Policy and Procedures | In place | Pyron | Yes. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. |
| IAM-01.2 | IAM-01 Identity and Access Management Policy and Procedures | In place | Pyron | Yes. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. |
| IAM-02.1 | IAM-02 Credentials Management Policy and Procedures | In place | Pyron | Yes. A password must meet a minimum length and is refused when it is common, entirely numeric or too like the person's own details, and it is stored only as a salted hash. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. |
| IAM-02.2 | IAM-02 Credentials Management Policy and Procedures | In place | Pyron | Yes. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. |
| IAM-03.1 | IAM-03 Identity Inventory | In place | Shared | Yes. Setup lists every person, guest, service account, API key, connection, stored login, automation, shared page and role in a workspace. Setup shows every role and what it allows, what any one person can do, and who can reach any one place (Roles, Explorer), and lists every change to roles (Roles, Activity). Every change in a workspace is recorded in plain words, whoever made it: a person, an automation, the AI or Support. What people view is recorded too, and so are attempts the permission engine refuses. The trail is kept for 24 months: records are only ever added, never edited, and each is cryptographically linked to the one before it, so tampering would be evident. Your part: review the people and service accounts in your workspace, and what they can reach. |
| IAM-04.1 | IAM-04 Separation of Duties | Partial | Pyron | No. One engineer builds and operates Pyron. Where a larger team would separate duties between people, Techly relies on controls that do not depend on a second person: required checks on every change, alerts on the most sensitive actions in its cloud accounts, and activity records kept in a separate archive account. What a person can see and do comes from their roles and from what is shared with them, and access to a place flows down to everything beneath it. Every operation in Pyron has a permission of its own, the permission engine's default answer is no, and only a role that holds the permission can add people, change roles or change the workspace's settings. |
| IAM-05.1 | IAM-05 Least Privilege | Partial | Shared | No. What a person can see and do comes from their roles and from what is shared with them, and access to a place flows down to everything beneath it. Every operation in Pyron has a permission of its own, the permission engine's default answer is no, and only a role that holds the permission can add people, change roles or change the workspace's settings. Our engineers sign in to AWS through IAM Identity Center, in sessions that expire, and the production database accepts only short-lived sign-in tokens, never a stored password. Administrator access is standing rather than raised for each task. Your part: give each person and service account only the roles they need. |
| IAM-06.1 | IAM-06 Access Provisioning | In place | Shared | Yes. What a person can see and do comes from their roles and from what is shared with them, and access to a place flows down to everything beneath it. Every operation in Pyron has a permission of its own, the permission engine's default answer is no, and only a role that holds the permission can add people, change roles or change the workspace's settings. Every change in a workspace is recorded in plain words, whoever made it: a person, an automation, the AI or Support. What people view is recorded too, and so are attempts the permission engine refuses. The trail is kept for 24 months: records are only ever added, never edited, and each is cryptographically linked to the one before it, so tampering would be evident. Your part: decide who is given which role in your workspace. |
| IAM-07.1 | IAM-07 Access Changes and Revocation | Partial | Shared | No. A workspace admin can suspend a person, which refuses every request they make from that moment, or remove them. There is no automatic deprovisioning from an identity provider (SCIM): when someone leaves, an admin suspends or removes them in Pyron. A person can sign out every other device at once, and a workspace admin can sign everyone out; either stops the access tokens already issued, not only the sessions. Resetting a password does not by itself sign out a person's other sessions. Staff read Techly's policies when they join and confirm each year that they follow them, use their own named account with two-step sign-in wherever a system offers it, report anything that may be an incident straight away, and lose their access on the day they leave; a breach of the policies can lead to access being removed. Security training beyond the policies is not yet documented. Your part: suspend or remove people in your workspace when they leave. |
| IAM-08.1 | IAM-08 Access Review | Partial | Shared | No. Setup shows every role and what it allows, what any one person can do, and who can reach any one place (Roles, Explorer), and lists every change to roles (Roles, Activity). The Access Control Policy has the Technical Director review, every quarter, who holds access to each of Techly's systems and that two-step sign-in is on for every account, and record the review. The policy took effect on 25 October 2026. Your part: review roles in your workspace at a set interval. |
| IAM-09.1 | IAM-09 Segregation of Privileged Access Roles | Partial | Pyron | No. Our engineers sign in to AWS through IAM Identity Center, in sessions that expire, and the production database accepts only short-lived sign-in tokens, never a stored password. Administrator access is standing rather than raised for each task. Emergency access to our AWS accounts is a separate permission set, and each use of it, like any sign-in as an account's root user, pages our on-call engineer. |
| IAM-10.1 | IAM-10 Management of Privileged Access Roles | Partial | Pyron | No. Our engineers sign in to AWS through IAM Identity Center, in sessions that expire, and the production database accepts only short-lived sign-in tokens, never a stored password. Administrator access is standing rather than raised for each task. Techly's support engineers can sign in to any workspace to help, only through Techly's Google Workspace, which enforces 2-step verification, and a Support session lasts at most 8 hours and cannot be extended. What Support views and changes is recorded on the workspace's audit trail. A workspace cannot yet switch this access off. A workspace admin, or Support, can view Pyron as a particular person. A view-as session needs a reason, cannot change anything, ends within 60 minutes, and is recorded on the audit trail, naming who viewed and as whom. |
| IAM-10.2 | IAM-10 Management of Privileged Access Roles | Partial | Pyron | No. Our engineers sign in to AWS through IAM Identity Center, in sessions that expire, and the production database accepts only short-lived sign-in tokens, never a stored password. Administrator access is standing rather than raised for each task. One engineer builds and operates Pyron. Where a larger team would separate duties between people, Techly relies on controls that do not depend on a second person: required checks on every change, alerts on the most sensitive actions in its cloud accounts, and activity records kept in a separate archive account. |
| IAM-11.1 | IAM-11 Service Customers Approval for Agreed Privileged Access Roles | Partial | Pyron | No. Techly's support engineers can sign in to any workspace to help, only through Techly's Google Workspace, which enforces 2-step verification, and a Support session lasts at most 8 hours and cannot be extended. What Support views and changes is recorded on the workspace's audit trail. A workspace cannot yet switch this access off. |
| IAM-12.1 | IAM-12 Unique Identities | In place | Pyron | Yes. Every change in a workspace is recorded in plain words, whoever made it: a person, an automation, the AI or Support. What people view is recorded too, and so are attempts the permission engine refuses. The trail is kept for 24 months: records are only ever added, never edited, and each is cryptographically linked to the one before it, so tampering would be evident. Integrations and automations act as service accounts, each holding roles like a person. An API key belongs to one service account, is stored only as a hash, can expire and can be revoked at any time, and what is done with it is recorded on the audit trail as that account. |
| IAM-13.1 | IAM-13 Strong Authentication | Partial | Shared | No. Two-step sign-in works with a passkey, an authenticator app or a code sent by email. A workspace admin can make it required for everyone or for chosen roles, and can switch off authenticator apps and emailed codes so that only passkeys, which resist phishing, are accepted. A workspace admin can connect a SAML or OpenID Connect identity provider (Microsoft Entra ID, Okta, Google Workspace and others) in Setup, test it, then allow it beside passwords or make it required. Required switches password sign-in off for everyone, with no fallback. Techly's support engineers can sign in to any workspace to help, only through Techly's Google Workspace, which enforces 2-step verification, and a Support session lasts at most 8 hours and cannot be extended. What Support views and changes is recorded on the workspace's audit trail. A workspace cannot yet switch this access off. Two-step sign-in to our AWS accounts is not yet set in code. Your part: make two-step sign-in required, or require it in your identity provider. |
| IAM-13.2 | IAM-13 Strong Authentication | In place | Pyron | Yes. Our services reach AWS through roles bound to each workload, and our build pipelines through short-lived OpenID Connect credentials, never through stored access keys. |
| IAM-14.1 | IAM-14 Credentials Management | In place | Shared | Yes. A password must meet a minimum length and is refused when it is common, entirely numeric or too like the person's own details, and it is stored only as a salted hash. Logins a workspace keeps in the Pyron Vault are stored encrypted, apart from the database. A hidden value is never shown to the AI, which reads only a hint of what it is for, and a value is only ever sent to the web addresses its login allows. Integrations and automations act as service accounts, each holding roles like a person. An API key belongs to one service account, is stored only as a hash, can expire and can be revoked at any time, and what is done with it is recorded on the audit trail as that account. Your part: keep integration credentials in the Pyron Vault, and give API keys an expiry. |
| IAM-15.1 | IAM-15 Authorization Mechanisms | In place | Pyron | Yes. Every change a person, an automation or the AI makes goes through the same path, which asks the permission engine before anything is written. What a person can see and do comes from their roles and from what is shared with them, and access to a place flows down to everything beneath it. Every operation in Pyron has a permission of its own, the permission engine's default answer is no, and only a role that holds the permission can add people, change roles or change the workspace's settings. |
| IPY-01.1 | IPY-01 Interoperability and Portability Policy and Procedures | Partial | Pyron | No. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. People can export a table's records as a spreadsheet. When a subscription ends there is a 30-day export window, then deletion within 90 days; deleting a workspace removes its database schema, its files, its stored secrets and its single sign-on connection, and backups age out on their normal rotation. There is no interoperability and portability policy of its own: the Records Management Policy covers what happens to a workspace's data when its subscription ends. |
| IPY-01.2 | IPY-01 Interoperability and Portability Policy and Procedures | Partial | Pyron | No. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. People can export a table's records as a spreadsheet. When a subscription ends there is a 30-day export window, then deletion within 90 days; deleting a workspace removes its database schema, its files, its stored secrets and its single sign-on connection, and backups age out on their normal rotation. There is no interoperability and portability policy of its own: the Records Management Policy covers what happens to a workspace's data when its subscription ends. |
| IPY-01.3 | IPY-01 Interoperability and Portability Policy and Procedures | Partial | Pyron | No. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. People can export a table's records as a spreadsheet. When a subscription ends there is a 30-day export window, then deletion within 90 days; deleting a workspace removes its database schema, its files, its stored secrets and its single sign-on connection, and backups age out on their normal rotation. There is no interoperability and portability policy of its own: the Records Management Policy covers what happens to a workspace's data when its subscription ends. |
| IPY-01.4 | IPY-01 Interoperability and Portability Policy and Procedures | Partial | Pyron | No. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. People can export a table's records as a spreadsheet. When a subscription ends there is a 30-day export window, then deletion within 90 days; deleting a workspace removes its database schema, its files, its stored secrets and its single sign-on connection, and backups age out on their normal rotation. There is no interoperability and portability policy of its own: the Records Management Policy covers what happens to a workspace's data when its subscription ends. |
| IPY-01.5 | IPY-01 Interoperability and Portability Policy and Procedures | Partial | Pyron | No. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. People can export a table's records as a spreadsheet. When a subscription ends there is a 30-day export window, then deletion within 90 days; deleting a workspace removes its database schema, its files, its stored secrets and its single sign-on connection, and backups age out on their normal rotation. There is no interoperability and portability policy of its own: the Records Management Policy covers what happens to a workspace's data when its subscription ends. |
| IPY-02.1 | IPY-02 Application Interface Availability | Partial | Pyron | No. People can export a table's records as a spreadsheet. When a subscription ends there is a 30-day export window, then deletion within 90 days; deleting a workspace removes its database schema, its files, its stored secrets and its single sign-on connection, and backups age out on their normal rotation. Integrations and automations act as service accounts, each holding roles like a person. An API key belongs to one service account, is stored only as a hash, can expire and can be revoked at any time, and what is done with it is recorded on the audit trail as that account. There is no export of a whole workspace through the API. |
| IPY-03.1 | IPY-03 Secure Interoperability and Portability Management | Partial | Pyron | No. Pyron is served only over HTTPS with TLS 1.2 or later, and tells browsers never to use plain HTTP; the database refuses an unencrypted connection, and file storage refuses an unencrypted request. Traffic between our own services inside the cluster is not encrypted. |
| IPY-04.1 | IPY-04 Data Portability Contractual Obligations | Partial | Pyron | No. People can export a table's records as a spreadsheet. When a subscription ends there is a 30-day export window, then deletion within 90 days; deleting a workspace removes its database schema, its files, its stored secrets and its single sign-on connection, and backups age out on their normal rotation. A Data Processing Agreement is not yet written. Until it is, the Privacy Statement sets out how customer data is handled, kept, returned and deleted. |
| I&S-01.1 | I&S-01 Infrastructure and Virtualization Security Policy and Procedures | Partial | Pyron | No. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. Our cloud accounts, network edge and source control are defined in code, changed through pull requests, and scanned for insecure settings (Checkov) on every change. There is no infrastructure security policy of its own: the Information Security, Cryptography and Change Management policies cover it. |
| I&S-01.2 | I&S-01 Infrastructure and Virtualization Security Policy and Procedures | Partial | Pyron | No. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. Our cloud accounts, network edge and source control are defined in code, changed through pull requests, and scanned for insecure settings (Checkov) on every change. There is no infrastructure security policy of its own: the Information Security, Cryptography and Change Management policies cover it. |
| I&S-02.1 | I&S-02 Capacity and Resource Planning | In place | Pyron | Yes. Alerts watch the database's storage, processor, memory and connections, and the cluster adds and removes servers automatically as the work scheduled on it changes. |
| I&S-03.1 | I&S-03 Network Security | In place | Pyron | Yes. Logs, metrics and traces from every part of the service are collected through OpenTelemetry and go to Grafana Cloud in Australia, with credentials and what is said to and by the AI removed first. Alerts watch errors, response times, database capacity, background work, certificates and credentials, each alert has a written runbook, and a watchdog pages if the monitoring itself stops reporting. Traffic leaving our servers passes through Cloudflare Gateway, which blocks known malware, phishing and command-and-control destinations and logs every destination, without decrypting traffic. If Gateway is unavailable, traffic continues without that filter rather than stopping: a risk we have accepted, so that an outage at the filter does not stop customers' automations. |
| I&S-03.2 | I&S-03 Network Security | Partial | Pyron | No. Pyron is served only over HTTPS with TLS 1.2 or later, and tells browsers never to use plain HTTP; the database refuses an unencrypted connection, and file storage refuses an unencrypted request. Traffic between our own services inside the cluster is not encrypted. |
| I&S-03.3 | I&S-03 Network Security | In place | Pyron | Yes. The database and the application have no public address: requests reach the application only through an encrypted Cloudflare tunnel, and network policies stop staging from ever reaching production. |
| I&S-03.4 | I&S-03 Network Security | In place | Pyron | Yes. Our cloud accounts, network edge and source control are defined in code, changed through pull requests, and scanned for insecure settings (Checkov) on every change. Every night, each infrastructure stack is compared with its code, and a difference is fixed in code. |
| I&S-03.5 | I&S-03 Network Security | In place | Pyron | Yes. Our cloud accounts, network edge and source control are defined in code, changed through pull requests, and scanned for insecure settings (Checkov) on every change. |
| I&S-04.1 | I&S-04 OS Hardening and Base Controls | Partial | Pyron | No. Our servers run on an image AWS manages (EKS Auto Mode), and each is replaced at least every 7 days with AWS's current image, so operating system updates arrive without waiting on anyone. Our cloud accounts, network edge and source control are defined in code, changed through pull requests, and scanned for insecure settings (Checkov) on every change. AWS Config and AWS Security Hub, which would check our cloud settings against best practice continuously, are not switched on. |
| I&S-05.1 | I&S-05 Production and Non-Production Environments | In place | Pyron | Yes. Staging and each pull request's preview run apart from production: they use a staging database, never production's, previews run on nodes of their own, and network policies stop staging from ever reaching production. They share production's AWS account and cluster. |
| I&S-05.2 | I&S-05 Production and Non-Production Environments | Partial | Pyron | No. Automated tests run on generated data. A database migration that rewrites rows is rehearsed on a copy of production restored inside our AWS account, which only the rehearsal can reach, and moving a workspace from Techly's earlier platform runs on a working copy that is deleted once the move is checked. |
| I&S-06.1 | I&S-06 Segmentation and Segregation | In place | Pyron | Yes. Each workspace's data lives in a database schema of its own, and every request is answered inside the schema of the workspace it was made to. Each workspace has its own environment in our authorisation service, and a sign-in names the workspace it was issued for, so no other workspace accepts it. The database server and the computing cluster are shared. |
| I&S-07.1 | I&S-07 Migration to Cloud Environments | Partial | Pyron | No. Pyron is served only over HTTPS with TLS 1.2 or later, and tells browsers never to use plain HTTP; the database refuses an unencrypted connection, and file storage refuses an unencrypted request. Traffic between our own services inside the cluster is not encrypted. Automated tests run on generated data. A database migration that rewrites rows is rehearsed on a copy of production restored inside our AWS account, which only the rehearsal can reach, and moving a workspace from Techly's earlier platform runs on a working copy that is deleted once the move is checked. |
| I&S-08.1 | I&S-08 Network Architecture Documentation | In place | Pyron | Yes. Information is classified Public, Internal, Confidential or Restricted, with handling rules for each. Everything a customer keeps in Pyron is Restricted: stored only in Pyron's production systems and with the providers our Privacy Statement names, and never copied to an email, a chat or a ticket. Techly keeps a risk register: each risk's likelihood, impact, owner and treatment. The Technical Director reviews it every quarter, a gap in a control, an exception to a policy or a finding from a scan stays on it until it is closed, and only a director may accept a risk. |
| I&S-09.1 | I&S-09 Network Defense | In place | Pyron | Yes. Cloudflare's managed firewall rules, including the OWASP Core Ruleset, run in front of Pyron, and requests to its API are rate-limited there. The database and the application have no public address: requests reach the application only through an encrypted Cloudflare tunnel, and network policies stop staging from ever reaching production. Traffic leaving our servers passes through Cloudflare Gateway, which blocks known malware, phishing and command-and-control destinations and logs every destination, without decrypting traffic. If Gateway is unavailable, traffic continues without that filter rather than stopping: a risk we have accepted, so that an outage at the filter does not stop customers' automations. |
| LOG-01.1 | LOG-01 Logging and Monitoring Policy and Procedures | In place | Pyron | Yes. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. |
| LOG-01.2 | LOG-01 Logging and Monitoring Policy and Procedures | In place | Pyron | Yes. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. |
| LOG-02.1 | LOG-02 Audit Logs Protection | In place | Pyron | Yes. Every change in a workspace is recorded in plain words, whoever made it: a person, an automation, the AI or Support. What people view is recorded too, and so are attempts the permission engine refuses. The trail is kept for 24 months: records are only ever added, never edited, and each is cryptographically linked to the one before it, so tampering would be evident. Activity on our AWS accounts is recorded by AWS CloudTrail into a separate archive account, where it is locked for 12 months. |
| LOG-03.1 | LOG-03 Security Monitoring and Alerting | Partial | Pyron | No. A sign-in as an account's root user, use of emergency access, or a change to an organisation policy or to our cloud activity logging pages our on-call engineer; a change to who can reach our AWS accounts, and a new finding of access from outside them, raise an alert. Every change in a workspace is recorded in plain words, whoever made it: a person, an automation, the AI or Support. What people view is recorded too, and so are attempts the permission engine refuses. The trail is kept for 24 months: records are only ever added, never edited, and each is cryptographically linked to the one before it, so tampering would be evident. Managed threat detection for our AWS accounts (Amazon GuardDuty), and detection of unusual sign-in patterns in Pyron, are not in place. |
| LOG-03.2 | LOG-03 Security Monitoring and Alerting | Partial | Pyron | No. A sign-in as an account's root user, use of emergency access, or a change to an organisation policy or to our cloud activity logging pages our on-call engineer; a change to who can reach our AWS accounts, and a new finding of access from outside them, raise an alert. Alerts that need someone page our on-call engineer through All Quiet. On-call is one engineer, with no second line. |
| LOG-04.1 | LOG-04 Audit Logs Access and Accountability | In place | Pyron | Yes. Every change in a workspace is recorded in plain words, whoever made it: a person, an automation, the AI or Support. What people view is recorded too, and so are attempts the permission engine refuses. The trail is kept for 24 months: records are only ever added, never edited, and each is cryptographically linked to the one before it, so tampering would be evident. People whose role allows it can export the audit trail, filtered or whole, as a spreadsheet or as a file for a security system (one event per line), and each export is itself recorded. |
| LOG-05.1 | LOG-05 Audit Logs Monitoring and Response | Planned | Pyron | No. Managed threat detection for our AWS accounts (Amazon GuardDuty), and detection of unusual sign-in patterns in Pyron, are not in place. |
| LOG-05.2 | LOG-05 Audit Logs Monitoring and Response | Partial | Pyron | No. Alerts that need someone page our on-call engineer through All Quiet. On-call is one engineer, with no second line. The Incident Management Policy sets out how an incident is found, rated, contained, investigated with its evidence preserved, and learned from, who leads it and when customers are told. Each Critical or High incident gets a written review within 10 business days, and an affected customer may ask for a summary of it. The policy took effect on 25 October 2026, and the yearly walk-through of an incident scenario it requires has not yet been held. |
| LOG-06.1 | LOG-06 Clock Synchronization | In place | Pyron | Yes. Our servers, the database and the network edge keep the time their providers synchronise, and every log and audit record carries a timestamp with its time zone. |
| LOG-07.1 | LOG-07 Logging Scope | In place | Pyron | Yes. Logs, metrics and traces from every part of the service are collected through OpenTelemetry and go to Grafana Cloud in Australia, with credentials and what is said to and by the AI removed first. Alerts watch errors, response times, database capacity, background work, certificates and credentials, each alert has a written runbook, and a watchdog pages if the monitoring itself stops reporting. Every change in a workspace is recorded in plain words, whoever made it: a person, an automation, the AI or Support. What people view is recorded too, and so are attempts the permission engine refuses. The trail is kept for 24 months: records are only ever added, never edited, and each is cryptographically linked to the one before it, so tampering would be evident. |
| LOG-07.2 | LOG-07 Logging Scope | In place | Pyron | Yes. Logs, metrics and traces from every part of the service are collected through OpenTelemetry and go to Grafana Cloud in Australia, with credentials and what is said to and by the AI removed first. Alerts watch errors, response times, database capacity, background work, certificates and credentials, each alert has a written runbook, and a watchdog pages if the monitoring itself stops reporting. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. |
| LOG-08.1 | LOG-08 Audit Logs Sanitization | Partial | Shared | No. Logs, metrics and traces from every part of the service are collected through OpenTelemetry and go to Grafana Cloud in Australia, with credentials and what is said to and by the AI removed first. Alerts watch errors, response times, database capacity, background work, certificates and credentials, each alert has a written runbook, and a watchdog pages if the monitoring itself stops reporting. Every change in a workspace is recorded in plain words, whoever made it: a person, an automation, the AI or Support. What people view is recorded too, and so are attempts the permission engine refuses. The trail is kept for 24 months: records are only ever added, never edited, and each is cryptographically linked to the one before it, so tampering would be evident. A customer cannot remove an entry from its audit trail, by design. Your part: keep secrets out of what you record in Pyron, in the Pyron Vault. |
| LOG-09.1 | LOG-09 Log Records | In place | Pyron | Yes. Every change in a workspace is recorded in plain words, whoever made it: a person, an automation, the AI or Support. What people view is recorded too, and so are attempts the permission engine refuses. The trail is kept for 24 months: records are only ever added, never edited, and each is cryptographically linked to the one before it, so tampering would be evident. |
| LOG-10.1 | LOG-10 Audit Records Protection | In place | Pyron | Yes. Every change in a workspace is recorded in plain words, whoever made it: a person, an automation, the AI or Support. What people view is recorded too, and so are attempts the permission engine refuses. The trail is kept for 24 months: records are only ever added, never edited, and each is cryptographically linked to the one before it, so tampering would be evident. Activity on our AWS accounts is recorded by AWS CloudTrail into a separate archive account, where it is locked for 12 months. |
| LOG-11.1 | LOG-11 Encryption Monitoring and Reporting | In place | Pyron | Yes. Activity on our AWS accounts is recorded by AWS CloudTrail into a separate archive account, where it is locked for 12 months. A key moves through AWS Key Management Service's own states, enabled, disabled and scheduled for deletion after a waiting period, and every change to a key is made in infrastructure code and recorded by AWS CloudTrail. The Cryptography Policy sets who holds the keys, and that a key suspected to be compromised is rotated and the data it protected re-encrypted. |
| LOG-12.1 | LOG-12 Transaction/Activity Logging | In place | Pyron | Yes. Activity on our AWS accounts is recorded by AWS CloudTrail into a separate archive account, where it is locked for 12 months. Encryption keys are created and held in AWS Key Management Service, never exported, and rotate automatically, with a separate key for customer data, for stored logins and for signing. |
| LOG-13.1 | LOG-13 Access Control Logs | In place | Pyron | Yes. Pyron runs on AWS and Cloudflare, with no data centre or server room of its own. The physical and environmental security of the facilities it runs in, including their power, cooling, cabling and the disposal of their storage media, is theirs, under their own independent certifications. |
| LOG-14.1 | LOG-14 Failures and Anomalies Reporting | In place | Pyron | Yes. Logs, metrics and traces from every part of the service are collected through OpenTelemetry and go to Grafana Cloud in Australia, with credentials and what is said to and by the AI removed first. Alerts watch errors, response times, database capacity, background work, certificates and credentials, each alert has a written runbook, and a watchdog pages if the monitoring itself stops reporting. |
| LOG-14.2 | LOG-14 Failures and Anomalies Reporting | Partial | Pyron | No. Alerts that need someone page our on-call engineer through All Quiet. On-call is one engineer, with no second line. |
| SEF-01.1 | SEF-01 Security Incident Management Policy and Procedures | Partial | Pyron | No. The Incident Management Policy sets out how an incident is found, rated, contained, investigated with its evidence preserved, and learned from, who leads it and when customers are told. Each Critical or High incident gets a written review within 10 business days, and an affected customer may ask for a summary of it. The policy took effect on 25 October 2026, and the yearly walk-through of an incident scenario it requires has not yet been held. |
| SEF-01.2 | SEF-01 Security Incident Management Policy and Procedures | Partial | Pyron | No. The Incident Management Policy sets out how an incident is found, rated, contained, investigated with its evidence preserved, and learned from, who leads it and when customers are told. Each Critical or High incident gets a written review within 10 business days, and an affected customer may ask for a summary of it. The policy took effect on 25 October 2026, and the yearly walk-through of an incident scenario it requires has not yet been held. |
| SEF-02.1 | SEF-02 Service Management Policy and Procedures | Partial | Pyron | No. The Incident Management Policy sets out how an incident is found, rated, contained, investigated with its evidence preserved, and learned from, who leads it and when customers are told. Each Critical or High incident gets a written review within 10 business days, and an affected customer may ask for a summary of it. The policy took effect on 25 October 2026, and the yearly walk-through of an incident scenario it requires has not yet been held. |
| SEF-02.2 | SEF-02 Service Management Policy and Procedures | Partial | Pyron | No. The Incident Management Policy sets out how an incident is found, rated, contained, investigated with its evidence preserved, and learned from, who leads it and when customers are told. Each Critical or High incident gets a written review within 10 business days, and an affected customer may ask for a summary of it. The policy took effect on 25 October 2026, and the yearly walk-through of an incident scenario it requires has not yet been held. |
| SEF-03.1 | SEF-03 Incident Response Plans | Partial | Pyron | No. The Incident Management Policy sets out how an incident is found, rated, contained, investigated with its evidence preserved, and learned from, who leads it and when customers are told. Each Critical or High incident gets a written review within 10 business days, and an affected customer may ask for a summary of it. The policy took effect on 25 October 2026, and the yearly walk-through of an incident scenario it requires has not yet been held. We notify an affected customer of a suspected or confirmed security incident affecting their data without undue delay and no later than 48 hours, and assess a possible eligible data breach under the Privacy Act 1988 (Cth) within 30 days. |
| SEF-04.1 | SEF-04 Incident Response Testing | Partial | Pyron | No. The Incident Management Policy sets out how an incident is found, rated, contained, investigated with its evidence preserved, and learned from, who leads it and when customers are told. Each Critical or High incident gets a written review within 10 business days, and an affected customer may ask for a summary of it. The policy took effect on 25 October 2026, and the yearly walk-through of an incident scenario it requires has not yet been held. |
| SEF-05.1 | SEF-05 Incident Response Metrics | Planned | Pyron | No. Security metrics, such as incidents, vulnerabilities and the time to fix them, are not yet measured or reported. |
| SEF-06.1 | SEF-06 Event Triage Processes | Partial | Pyron | No. Alerts that need someone page our on-call engineer through All Quiet. On-call is one engineer, with no second line. The Incident Management Policy sets out how an incident is found, rated, contained, investigated with its evidence preserved, and learned from, who leads it and when customers are told. Each Critical or High incident gets a written review within 10 business days, and an affected customer may ask for a summary of it. The policy took effect on 25 October 2026, and the yearly walk-through of an incident scenario it requires has not yet been held. |
| SEF-07.1 | SEF-07 Incident Management and Response | Partial | Pyron | No. The Incident Management Policy sets out how an incident is found, rated, contained, investigated with its evidence preserved, and learned from, who leads it and when customers are told. Each Critical or High incident gets a written review within 10 business days, and an affected customer may ask for a summary of it. The policy took effect on 25 October 2026, and the yearly walk-through of an incident scenario it requires has not yet been held. The Vulnerability Management Policy sets how fast a finding is fixed or accepted with a reason: a critical one within 7 days, a high one within 30, and others at the component's next update. One that is being exploited, or that exposes customer data, is an incident, handled at once. |
| SEF-07.2 | SEF-07 Incident Management and Response | Partial | Pyron | No. The Incident Management Policy sets out how an incident is found, rated, contained, investigated with its evidence preserved, and learned from, who leads it and when customers are told. Each Critical or High incident gets a written review within 10 business days, and an affected customer may ask for a summary of it. The policy took effect on 25 October 2026, and the yearly walk-through of an incident scenario it requires has not yet been held. |
| SEF-08.1 | SEF-08 Security Breach Notification | In place | Shared | Yes. We notify an affected customer of a suspected or confirmed security incident affecting their data without undue delay and no later than 48 hours, and assess a possible eligible data breach under the Privacy Act 1988 (Cth) within 30 days. Your part: notify the individuals affected: where we act as your processor, the Privacy Statement says that is yours to do. |
| SEF-08.2 | SEF-08 Security Breach Notification | In place | Pyron | Yes. We notify an affected customer of a suspected or confirmed security incident affecting their data without undue delay and no later than 48 hours, and assess a possible eligible data breach under the Privacy Act 1988 (Cth) within 30 days. |
| SEF-09.1 | SEF-09 Incident Records Management | In place | Pyron | Yes. Each incident is recorded in Techly's issue tracker with its timeline, its cause and its follow-up actions. |
| SEF-09.2 | SEF-09 Incident Records Management | Partial | Pyron | No. Each incident is recorded in Techly's issue tracker with its timeline, its cause and its follow-up actions. The Incident Management Policy sets out how an incident is found, rated, contained, investigated with its evidence preserved, and learned from, who leads it and when customers are told. Each Critical or High incident gets a written review within 10 business days, and an affected customer may ask for a summary of it. The policy took effect on 25 October 2026, and the yearly walk-through of an incident scenario it requires has not yet been held. |
| SEF-10.1 | SEF-10 Points of Contact Maintenance | Partial | Pyron | No. We notify an affected customer of a suspected or confirmed security incident affecting their data without undue delay and no later than 48 hours, and assess a possible eligible data breach under the Privacy Act 1988 (Cth) within 30 days. Contacts for law enforcement and for ASD's reporting service are not yet listed in a policy. |
| SEF-10.2 | SEF-10 Points of Contact Maintenance | Partial | Pyron | No. We notify an affected customer of a suspected or confirmed security incident affecting their data without undue delay and no later than 48 hours, and assess a possible eligible data breach under the Privacy Act 1988 (Cth) within 30 days. Contacts for law enforcement and for ASD's reporting service are not yet listed in a policy. |
| STA-01.1 | STA-01 Supply Chain Risk Management Policies and Procedures | Partial | Pyron | No. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. The Supplier Security Policy sets how a provider is chosen (what it will receive and where, its security, its data processing terms, and how we would leave it) and has each one reviewed every year. Copies of each provider's data processing terms are still being collected. |
| STA-01.2 | STA-01 Supply Chain Risk Management Policies and Procedures | Partial | Pyron | No. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. The Supplier Security Policy sets how a provider is chosen (what it will receive and where, its security, its data processing terms, and how we would leave it) and has each one reviewed every year. Copies of each provider's data processing terms are still being collected. |
| STA-02.1 | STA-02 SSRM Policy and Procedures | In place | Pyron | Yes. This Trust Centre sets out what Pyron does and what a customer does, action by action, against ASD's Essentials for cloud, and names the owner of each answer to the Cloud Security Alliance's questionnaire. |
| STA-02.2 | STA-02 SSRM Policy and Procedures | In place | Pyron | Yes. This Trust Centre sets out what Pyron does and what a customer does, action by action, against ASD's Essentials for cloud, and names the owner of each answer to the Cloud Security Alliance's questionnaire. |
| STA-03.1 | STA-03 SSRM Supply Chain | Partial | Pyron | No. This Trust Centre sets out what Pyron does and what a customer does, action by action, against ASD's Essentials for cloud, and names the owner of each answer to the Cloud Security Alliance's questionnaire. The Supplier Security Policy sets how a provider is chosen (what it will receive and where, its security, its data processing terms, and how we would leave it) and has each one reviewed every year. Copies of each provider's data processing terms are still being collected. |
| STA-04.1 | STA-04 SSRM Guidance | In place | Pyron | Yes. This Trust Centre sets out what Pyron does and what a customer does, action by action, against ASD's Essentials for cloud, and names the owner of each answer to the Cloud Security Alliance's questionnaire. |
| STA-05.1 | STA-05 SSRM Control Ownership | In place | Pyron | Yes. This Trust Centre sets out what Pyron does and what a customer does, action by action, against ASD's Essentials for cloud, and names the owner of each answer to the Cloud Security Alliance's questionnaire. |
| STA-06.1 | STA-06 SSRM Documentation Review | In place | Pyron | Yes. This Trust Centre sets out what Pyron does and what a customer does, action by action, against ASD's Essentials for cloud, and names the owner of each answer to the Cloud Security Alliance's questionnaire. |
| STA-07.1 | STA-07 SSRM Control Implementation | Partial | Pyron | No. This Trust Centre sets out what Pyron does and what a customer does, action by action, against ASD's Essentials for cloud, and names the owner of each answer to the Cloud Security Alliance's questionnaire. Pyron holds no security certification and has had no independent penetration test. |
| STA-08.1 | STA-08 Supply Chain Inventory | In place | Pyron | Yes. Every service provider that handles customer data is named on Data locations and in our Privacy Statement, with what it receives and where, and a change to that list is recorded in the statement's revision history. |
| STA-09.1 | STA-09 Service Bill of Material (BOM) | Partial | Pyron | No. Locked dependency files list every library Pyron is built from, at its exact version. No formal software bill of materials is produced from them. |
| STA-09.2 | STA-09 Service Bill of Material (BOM) | Partial | Pyron | No. Locked dependency files list every library Pyron is built from, at its exact version. No formal software bill of materials is produced from them. |
| STA-10.1 | STA-10 Supply Chain Risk Management | Partial | Pyron | No. The Supplier Security Policy sets how a provider is chosen (what it will receive and where, its security, its data processing terms, and how we would leave it) and has each one reviewed every year. Copies of each provider's data processing terms are still being collected. Techly keeps a risk register: each risk's likelihood, impact, owner and treatment. The Technical Director reviews it every quarter, a gap in a control, an exception to a policy or a finding from a scan stays on it until it is closed, and only a director may accept a risk. |
| STA-11.1 | STA-11 Primary Service and Contractual Agreement | Partial | Pyron | No. A Data Processing Agreement is not yet written. Until it is, the Privacy Statement sets out how customer data is handled, kept, returned and deleted. This Trust Centre publishes our security overview, where each kind of data is held and these self-assessments, openly and each with a version and a date. |
| STA-12.1 | STA-12 Supply Chain Agreement Review | Partial | Pyron | No. Every service provider that handles customer data is named on Data locations and in our Privacy Statement, with what it receives and where, and a change to that list is recorded in the statement's revision history. The Supplier Security Policy sets how a provider is chosen (what it will receive and where, its security, its data processing terms, and how we would leave it) and has each one reviewed every year. Copies of each provider's data processing terms are still being collected. |
| STA-13.1 | STA-13 Supply Chain Compliance Assessment | Partial | Pyron | No. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. This Trust Centre publishes our security overview, where each kind of data is held and these self-assessments, openly and each with a version and a date. There is no internal audit of conformance yet. |
| STA-14.1 | STA-14 Supply Chain Service Agreement Compliance | Partial | Pyron | No. Every service provider that handles customer data is named on Data locations and in our Privacy Statement, with what it receives and where, and a change to that list is recorded in the statement's revision history. The Supplier Security Policy sets how a provider is chosen (what it will receive and where, its security, its data processing terms, and how we would leave it) and has each one reviewed every year. Copies of each provider's data processing terms are still being collected. |
| STA-15.1 | STA-15 Supply Chain Governance Review | Partial | Pyron | No. Every service provider that handles customer data is named on Data locations and in our Privacy Statement, with what it receives and where, and a change to that list is recorded in the statement's revision history. The Supplier Security Policy sets how a provider is chosen (what it will receive and where, its security, its data processing terms, and how we would leave it) and has each one reviewed every year. Copies of each provider's data processing terms are still being collected. |
| STA-16.1 | STA-16 Supply Chain Data Security Assessment | Partial | Pyron | No. Every service provider that handles customer data is named on Data locations and in our Privacy Statement, with what it receives and where, and a change to that list is recorded in the statement's revision history. The Supplier Security Policy sets how a provider is chosen (what it will receive and where, its security, its data processing terms, and how we would leave it) and has each one reviewed every year. Copies of each provider's data processing terms are still being collected. |
| TVM-01.1 | TVM-01 Threat and Vulnerability Management Policy and Procedures | In place | Pyron | Yes. The Vulnerability Management Policy sets how fast a finding is fixed or accepted with a reason: a critical one within 7 days, a high one within 30, and others at the component's next update. One that is being exploited, or that exposes customer data, is an incident, handled at once. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. |
| TVM-01.2 | TVM-01 Threat and Vulnerability Management Policy and Procedures | In place | Pyron | Yes. The Vulnerability Management Policy sets how fast a finding is fixed or accepted with a reason: a critical one within 7 days, a high one within 30, and others at the component's next update. One that is being exploited, or that exposes customer data, is an incident, handled at once. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. |
| TVM-02.1 | TVM-02 Malware and Malicious Instructions Protection Policy and Procedures | In place | Pyron | Yes. Every uploaded file is scanned for malware before anyone can open it, and a file that holds malware is removed. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. |
| TVM-02.2 | TVM-02 Malware and Malicious Instructions Protection Policy and Procedures | In place | Pyron | Yes. Every uploaded file is scanned for malware before anyone can open it, and a file that holds malware is removed. Techly's Information Security Policy and the thirteen policies under it, among them Access Control, Acceptable Use, Business Continuity, Cryptography, Logging and Monitoring, Secure Development, Supplier Security and Vulnerability Management, are published in this Trust Centre. Each names its owner and is reviewed every year. |
| TVM-03.1 | TVM-03 Vulnerability Identification | In place | Pyron | Yes. Every dependency is scanned for known vulnerabilities on each change and every day. A change that adds a high or critical advisory is blocked, and an accepted finding is recorded with its reason and an expiry, so it is looked at again. Our servers run on an image AWS manages (EKS Auto Mode), and each is replaced at least every 7 days with AWS's current image, so operating system updates arrive without waiting on anyone. |
| TVM-04.1 | TVM-04 Threat Analysis and Modelling | Partial | Pyron | No. Threat intelligence reaches us through the services that carry it: new advisories for our dependencies every day, the threat categories our outbound filter blocks, and Cloudflare's managed firewall rules. Gathering it as a process of its own, including membership of security forums, is not yet documented. Techly keeps a risk register: each risk's likelihood, impact, owner and treatment. The Technical Director reviews it every quarter, a gap in a control, an exception to a policy or a finding from a scan stays on it until it is closed, and only a director may accept a risk. |
| TVM-04.2 | TVM-04 Threat Analysis and Modelling | Planned | Pyron | No. Threat models are not yet documented. |
| TVM-05.1 | TVM-05 Detection Updates | In place | Pyron | Yes. Every dependency is scanned for known vulnerabilities on each change and every day. A change that adds a high or critical advisory is blocked, and an accepted finding is recorded with its reason and an expiry, so it is looked at again. Traffic leaving our servers passes through Cloudflare Gateway, which blocks known malware, phishing and command-and-control destinations and logs every destination, without decrypting traffic. If Gateway is unavailable, traffic continues without that filter rather than stopping: a risk we have accepted, so that an outage at the filter does not stop customers' automations. Every uploaded file is scanned for malware before anyone can open it, and a file that holds malware is removed. |
| TVM-06.1 | TVM-06 External Library Vulnerabilities | In place | Pyron | Yes. Every dependency is scanned for known vulnerabilities on each change and every day. A change that adds a high or critical advisory is blocked, and an accepted finding is recorded with its reason and an expiry, so it is looked at again. Dependency updates are proposed automatically every week, once a release is 14 days old, as pull requests that pass the same checks as any change; an update that fixes a known advisory is proposed at once. Nothing merges by itself. |
| TVM-07.1 | TVM-07 Penetration Testing | Planned | Pyron | No. Pyron holds no security certification and has had no independent penetration test. |
| TVM-08.1 | TVM-08 Vulnerability Remediation Schedule | In place | Pyron | Yes. The Vulnerability Management Policy sets how fast a finding is fixed or accepted with a reason: a critical one within 7 days, a high one within 30, and others at the component's next update. One that is being exploited, or that exposes customer data, is an incident, handled at once. The Change Management Policy sets out how every change to Pyron is made, checked, released and recorded, including emergency changes, and it is reviewed every year. |
| TVM-09.1 | TVM-09 Vulnerability Prioritization | Partial | Pyron | No. The Vulnerability Management Policy sets how fast a finding is fixed or accepted with a reason: a critical one within 7 days, a high one within 30, and others at the component's next update. One that is being exploited, or that exposes customer data, is an incident, handled at once. Every dependency is scanned for known vulnerabilities on each change and every day. A change that adds a high or critical advisory is blocked, and an accepted finding is recorded with its reason and an expiry, so it is looked at again. A vulnerability is prioritised by its advisory's severity, not against a named framework. |
| TVM-10.1 | TVM-10 Threat Response | Partial | Pyron | No. Techly keeps a risk register: each risk's likelihood, impact, owner and treatment. The Technical Director reviews it every quarter, a gap in a control, an exception to a policy or a finding from a scan stays on it until it is closed, and only a director may accept a risk. Threats are rated on the risk register's own scale, not against a named framework. |
| TVM-11.1 | TVM-11 Vulnerability Management Reporting | In place | Pyron | Yes. Every dependency is scanned for known vulnerabilities on each change and every day. A change that adds a high or critical advisory is blocked, and an accepted finding is recorded with its reason and an expiry, so it is looked at again. Techly keeps a risk register: each risk's likelihood, impact, owner and treatment. The Technical Director reviews it every quarter, a gap in a control, an exception to a policy or a finding from a scan stays on it until it is closed, and only a director may accept a risk. |
| TVM-12.1 | TVM-12 Vulnerability Management Metrics | Planned | Pyron | No. Security metrics, such as incidents, vulnerabilities and the time to fix them, are not yet measured or reported. |
| UEM-01.1 | UEM-01 Endpoint Devices Policy and Procedures | Partial | Pyron | No. A device used for Techly work must have its disk encrypted, a screen lock that engages within a few minutes, and a supported operating system kept up to date (Acceptable Use Policy). Each person confirms this when they join and every year; nothing enforces it centrally. |
| UEM-01.2 | UEM-01 Endpoint Devices Policy and Procedures | Partial | Pyron | No. A device used for Techly work must have its disk encrypted, a screen lock that engages within a few minutes, and a supported operating system kept up to date (Acceptable Use Policy). Each person confirms this when they join and every year; nothing enforces it centrally. |
| UEM-02.1 | UEM-02 Application and Service Approval | Partial | Pyron | No. A device used for Techly work must have its disk encrypted, a screen lock that engages within a few minutes, and a supported operating system kept up to date (Acceptable Use Policy). Each person confirms this when they join and every year; nothing enforces it centrally. |
| UEM-03.1 | UEM-03 Compatibility | Planned | Pyron | No. The devices staff use are not managed centrally: there is no inventory, enforcement or remote wipe of them. |
| UEM-04.1 | UEM-04 Endpoint Inventory | Planned | Pyron | No. The devices staff use are not managed centrally: there is no inventory, enforcement or remote wipe of them. |
| UEM-05.1 | UEM-05 Endpoint Management | Planned | Pyron | No. The devices staff use are not managed centrally: there is no inventory, enforcement or remote wipe of them. |
| UEM-06.1 | UEM-06 Automatic Lock Screen | Partial | Pyron | No. A device used for Techly work must have its disk encrypted, a screen lock that engages within a few minutes, and a supported operating system kept up to date (Acceptable Use Policy). Each person confirms this when they join and every year; nothing enforces it centrally. |
| UEM-07.1 | UEM-07 Operating Systems | Planned | Pyron | No. The devices staff use are not managed centrally: there is no inventory, enforcement or remote wipe of them. |
| UEM-08.1 | UEM-08 Storage Encryption | Partial | Pyron | No. A device used for Techly work must have its disk encrypted, a screen lock that engages within a few minutes, and a supported operating system kept up to date (Acceptable Use Policy). Each person confirms this when they join and every year; nothing enforces it centrally. |
| UEM-09.1 | UEM-09 Anti-Malware Detection and Prevention | Planned | Pyron | No. The devices staff use are not managed centrally: there is no inventory, enforcement or remote wipe of them. |
| UEM-10.1 | UEM-10 Software Firewall | Planned | Pyron | No. The devices staff use are not managed centrally: there is no inventory, enforcement or remote wipe of them. |
| UEM-11.1 | UEM-11 Data Loss Prevention | Planned | Pyron | No. The devices staff use are not managed centrally: there is no inventory, enforcement or remote wipe of them. |
| UEM-12.1 | UEM-12 Remote Locate | Planned | Pyron | No. The devices staff use are not managed centrally: there is no inventory, enforcement or remote wipe of them. |
| UEM-13.1 | UEM-13 Remote Wipe | Planned | Pyron | No. The devices staff use are not managed centrally: there is no inventory, enforcement or remote wipe of them. |
| UEM-14.1 | UEM-14 Third-Party Endpoint Security Posture | Planned | Pyron | No. The devices staff use are not managed centrally: there is no inventory, enforcement or remote wipe of them. |