PYRON Trust Centre
ISO/IEC 27001 Statement of Applicability
All 93 controls of ISO/IEC 27001:2022 Annex A, each with where Pyron stands today and how it is met.
Pyron holds no ISO/IEC 27001 certificate. This Statement of Applicability is our own mapping toward the standard, not the output of an audit: it lists every control in Annex A, says whether it applies to Pyron and where it stands today, and how it is met. A certification audit would follow only when a customer needs one.
- Every control applies. Pyron is a cloud service run by a small company, and nothing in Annex A falls outside that. Where a control is about the facilities Pyron runs in, it is met by AWS's and Cloudflare's, and the row says so.
- Status is computed from the same control register as every other assessment in this Trust Centre, so the same fact never reads two ways. Planned means it is not in place today; partial means part of it is, and the row says which part is missing.
Control titles are ISO's, quoted to name each control; the standard itself is published by ISO. The Security overview describes each control in full, and the policies set out how Techly runs them.
- In place
- 29
- Partial
- 60
- Planned
- 4
- Not applicable
- 0
Showing 93 of 93
| Reference | Requirement | Status | How we meet it |
|---|---|---|---|
| A.5.1 | Policies for information security | In place | 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. |
| A.5.2 | Information security roles and responsibilities | In place | 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. |
| A.5.3 | Segregation of duties | Partial | 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. |
| A.5.4 | Management responsibilities | Partial | 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. 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. 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. |
| A.5.5 | Contact with authorities | In place | 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. |
| A.5.6 | Contact with special interest groups | Partial | 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. |
| A.5.7 | Threat intelligence | Partial | 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. |
| A.5.8 | Information security in project management | Partial | 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. |
| A.5.9 | Inventory of information and other associated assets | In place | 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. 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. |
| A.5.10 | Acceptable use of information and other associated assets | Partial | 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. 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. |
| A.5.11 | Return of assets | Partial | 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. |
| A.5.12 | Classification of information | In place | 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. |
| A.5.13 | Labelling of information | Partial | 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. Information takes its level from its kind, as the policy lists, rather than from a label on each item. |
| A.5.14 | Information transfer | Partial | 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. 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. |
| A.5.15 | Access control | In place | 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. 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. 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. |
| A.5.16 | Identity management | In place | 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 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. 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.5.17 | Authentication information | In place | 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. 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. 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. |
| A.5.18 | Access rights | In place | 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. 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). 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.5.19 | Information security in supplier relationships | Partial | 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. |
| A.5.20 | Addressing information security within supplier agreements | Partial | 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. |
| A.5.21 | Managing information security in the ICT supply chain | Partial | 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. 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. 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. |
| A.5.22 | Monitoring, review and change management of supplier services | Partial | 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. |
| A.5.23 | Information security for use of cloud services | Partial | 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. 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. |
| A.5.24 | Information security incident management planning and preparation | Partial | 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. 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. Alerts that need someone page our on-call engineer through All Quiet. On-call is one engineer, with no second line. |
| A.5.25 | Assessment and decision on information security events | Partial | 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. Alerts that need someone page our on-call engineer through All Quiet. On-call is one engineer, with no second line. |
| A.5.26 | Response to information security incidents | Partial | 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. 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. |
| A.5.27 | Learning from information security incidents | Partial | 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. |
| A.5.28 | Collection of evidence | Partial | 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. 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. |
| A.5.29 | Information security during disruption | Partial | 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. 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. |
| A.5.30 | ICT readiness for business continuity | Partial | 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 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. A full restore from backup has not yet been tested. The Business Continuity Policy schedules one every quarter. |
| A.5.31 | Legal, statutory, regulatory and contractual requirements | In place | 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. 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. |
| A.5.32 | Intellectual property rights | Planned | The licences of the open-source software Pyron is built on are not yet checked automatically. |
| A.5.33 | Protection of records | In place | 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. 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. 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.5.34 | Privacy and protection of PII | In place | 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. 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. |
| A.5.35 | Independent review of information security | Planned | Pyron holds no security certification and has had no independent penetration test. |
| A.5.36 | Compliance with policies, rules and standards for information security | Partial | 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. Whether the policies are followed has not yet been reviewed by anyone independent. |
| A.5.37 | Documented operating procedures | In place | 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. |
| A.6.1 | Screening | Planned | Screening before someone joins, and the security terms of employment and confidentiality agreements, are not yet documented in a policy. |
| A.6.2 | Terms and conditions of employment | Partial | 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. |
| A.6.3 | Information security awareness, education and training | Partial | 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. |
| A.6.4 | Disciplinary process | Partial | 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. |
| A.6.5 | Responsibilities after termination or change of employment | Partial | 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. Screening before someone joins, and the security terms of employment and confidentiality agreements, are not yet documented in a policy. |
| A.6.6 | Confidentiality or non-disclosure agreements | Partial | Screening before someone joins, and the security terms of employment and confidentiality agreements, are not yet documented in a policy. 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. |
| A.6.7 | Remote working | Partial | 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. |
| A.6.8 | Information security event reporting | Partial | 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. Anyone can report a vulnerability to security@pyron.io, as our security.txt says. A report is acknowledged within 5 business days, and the Website Terms set out what good-faith testing and disclosure are. |
| A.7.1 | Physical security perimeters | Partial | 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. |
| A.7.2 | Physical entry | Partial | 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. |
| A.7.3 | Securing offices, rooms and facilities | Partial | 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. |
| A.7.4 | Physical security monitoring | Partial | 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. |
| A.7.5 | Protecting against physical and environmental threats | In place | 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.7.6 | Working in secure areas | In place | 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.7.7 | Clear desk and clear screen | Partial | 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. |
| A.7.8 | Equipment siting and protection | In place | 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.7.9 | Security of assets off-premises | Partial | 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. |
| A.7.10 | Storage media | Partial | 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. 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. |
| A.7.11 | Supporting utilities | In place | 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.7.12 | Cabling security | In place | 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.7.13 | Equipment maintenance | In place | 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. 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. |
| A.7.14 | Secure disposal or re-use of equipment | Partial | 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. |
| A.8.1 | User endpoint devices | Partial | 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. The devices staff use are not managed centrally: there is no inventory, enforcement or remote wipe of them. |
| A.8.2 | Privileged access rights | Partial | 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. 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. |
| A.8.3 | Information access restriction | In place | 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. 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. |
| A.8.4 | Access to source code | Partial | Pyron's source code is held in a private GitHub repository. Our GitHub organisation requires two-factor authentication, and secrets are kept out of the code. 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.8.5 | Secure authentication | Partial | 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. A workspace admin chooses how long a person stays signed in (1, 7 or 30 days) and whether an idle session signs out (after 30 minutes, 2 hours or 8 hours). 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. An account is not locked after failed sign-in attempts. Sign-in attempts are rate-limited at our network edge. People sign in with a password and two-step sign-in, or through SAML or OpenID Connect single sign-on; integrations use API keys over HTTPS. No legacy protocol is offered. |
| A.8.6 | Capacity management | In place | 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. |
| A.8.7 | Protection against malware | Partial | Every uploaded file is scanned for malware before anyone can open it, and a file that holds malware is removed. 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. The devices staff use are not managed centrally: there is no inventory, enforcement or remote wipe of them. |
| A.8.8 | Management of technical vulnerabilities | Partial | 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. Anyone can report a vulnerability to security@pyron.io, as our security.txt says. A report is acknowledged within 5 business days, and the Website Terms set out what good-faith testing and disclosure are. Pyron holds no security certification and has had no independent penetration test. |
| A.8.9 | Configuration management | Partial | 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. 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. |
| A.8.10 | Information deletion | In place | 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. 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. |
| A.8.11 | Data masking | Partial | Pyron AI runs behind Amazon Bedrock Guardrails, which check what people ask for prompt attacks and harmful content, and check its answers for harmful content and credentials. An intervention steers the AI back on course and is recorded. 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. 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. Masking applies to what reaches our logs and the AI; Pyron does not mask the values in records. |
| A.8.12 | Data leakage prevention | Partial | 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. 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. Pyron AI runs behind Amazon Bedrock Guardrails, which check what people ask for prompt attacks and harmful content, and check its answers for harmful content and credentials. An intervention steers the AI back on course and is recorded. 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. Outbound traffic is not inspected for the data it carries. |
| A.8.13 | Information backup | Partial | 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. Backups are held in Melbourne only, in the same AWS account as production: there is no copy in a second region or account yet. A full restore from backup has not yet been tested. The Business Continuity Policy schedules one every quarter. |
| A.8.14 | Redundancy of information processing facilities | Partial | 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. |
| A.8.15 | Logging | In place | 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. 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. |
| A.8.16 | Monitoring activities | Partial | 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. 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. Managed threat detection for our AWS accounts (Amazon GuardDuty), and detection of unusual sign-in patterns in Pyron, are not in place. Alerts that need someone page our on-call engineer through All Quiet. On-call is one engineer, with no second line. |
| A.8.17 | Clock synchronization | In place | 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. |
| A.8.18 | Use of privileged utility programs | Partial | 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. |
| A.8.19 | Installation of software on operational systems | Partial | 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. 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. 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.8.20 | Networks security | Partial | 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. Cloudflare's managed firewall rules, including the OWASP Core Ruleset, run in front of Pyron, and requests to its API are rate-limited there. 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. |
| A.8.21 | Security of network services | In place | Cloudflare's managed firewall rules, including the OWASP Core Ruleset, run in front of Pyron, and requests to its API are rate-limited there. 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. 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. |
| A.8.22 | Segregation of networks | In place | 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. 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. 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. |
| A.8.23 | Web filtering | Partial | 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. This filter covers traffic leaving Pyron's servers. |
| A.8.24 | Use of cryptography | Partial | 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. 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. |
| A.8.25 | Secure development life cycle | Partial | 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. 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.8.26 | Application security requirements | In place | 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. When Pyron fetches a web address for an automation or the assistant, it refuses private and internal addresses. A webhook with a signing secret is checked by its signature and its time, so an old one cannot be replayed. |
| A.8.27 | Secure system architecture and engineering principles | In place | 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. Pages and automations run as programs in isolated sandboxes (Cloudflare Workers) with no network access of their own. A program reaches records only by asking Pyron, which checks permissions as it does for every other request. 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.8.28 | Secure coding | Partial | Static analysis runs on every change, including security rules for our code, our container files and our build workflows. Our code is scanned for secrets on every change, and GitHub refuses a push that contains one. 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.8.29 | Security testing in development and acceptance | Partial | 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. Pyron holds no security certification and has had no independent penetration test. |
| A.8.30 | Outsourced development | Partial | 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.8.31 | Separation of development, test and production environments | In place | 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. |
| A.8.32 | Change management | Partial | 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 shared page, automation or report changes only when someone with the right to publish it does. Earlier published versions are kept (the last 20 of a page or a report, every one of an automation) and can be restored. |
| A.8.33 | Test information | Partial | 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. |
| A.8.34 | Protection of information systems during audit testing | Planned | Pyron holds no security certification and has had no independent penetration test. |