| Trust CenterTriagen was founded by experienced technology and business professionals with expertise in AI, secure software development, and occupational health processes. We have designed and built our platform with privacy, information security, and responsible AI as core principles
Downloadable security policies, compliance reports, and certificates. Some documents may require an access request.
Our Statement of Applicability for ISO27001:2022
Specific security measures this organization has implemented, alongside their current operational status.
Procedures for assessing and treating information security risks are established and implemented. **Requirements** - The risk management process should include: criteria for risk assessment and risk acceptance, procedures for identifying, analysing, evaluating, treating and accepting risks, and treatment plans. - The process should be documented, approved, and kept up to date.
Appropriate treatment options and controls are established for information security risks. **Requirements** - The organisation should select a risk treatment option (accept, reduce, transfer, avoid) for each risk and establish all controls necessary to implement the selected information security risk treatment option(s). - The organisation should formulate an information security risk treatment plan, and risk owners should accept this plan and any residual risks. -**Specific requirement for ISO 27001:** The organisation should compare the established controls with Annex A of the ISO27001 standard and incorporate the results into a statement of applicability (SoA). - If the organisation can and wants to take out cyber insurance as part of the risk treatment, the following matters must be taken into account: the need to insure information security risks, the extent to which information security risks are (or can be) transferred (and where not, and therefore other measures are necessary), and the conditions and requirements that the insurer sets in the context of the policy.
Internal and external risks to which the organisation is exposed are identified, analysed, evaluated, reported, and documented. **Requirements** - The organisation should identify all risks that could affect the availability, integrity, and/or confidentiality (AIC) of relevant information and services. - The organisation should document how information and services relate to business functions, systems, applications, and processes (BIA), based on the availability, integrity, and confidentiality (AIC) of this information and supporting assets. - The organisation should appoint risk acceptance criteria and risk owners. The risk owners should approve the risk assessments - Risk assessments should be performed at planned intervals, or when significant changes are proposed or occur. - The results of risk assessments should be documented. **Definitions** **AIC:** Availability, integrity, and confidentiality **BIA:** Business impact analysis
Operational plans are defined and implemented. **Requirements** * The operational planning should provide for achieving the information security requirements and objectives. * Measurable criteria should be established for this and associated process control should be implemented. * The planning (and progress on it) should be documented and kept up to date.
The organisation must determine what internal and external communication is relevant to the information security management system. **Requirements** - The communication structure must include the following elements: what to communicate, when to communicate, with whom to communicate, and how to communicate.
The organisation should define the scope of its ISMS, taking into account the relevant issues, the stakeholder requirements including legal, statutory, regulatory, and contractual requirements, and the interfaces and dependencies between the activities that the organisation itself carries out and activities that other organisations carry out. **Requirements** - This information should be documented and kept up to date. **Definitions** **ISMS:** Information Security Management System
System controls the creation, approval, distribution, and maintenance of documented information. **Requirements:** - Approval before distribution and use - Version control and identification of changes - Prevention of unintended use of obsolete documents
Information security rules and procedures are defined and communicated. **Requirements** - The policy should be appropriate to the purpose of the organisation, contain information security objectives, and include commitments to meet applicable information security requirements and to continuously improve the information security management system. - The policy should be documented, approved, published, communicated, and kept up to date.
The information security objectives - including required resources - are established, approved, implemented, and periodically updated. **Requirements** - When establishing information security objectives, the organisation should consider the context of the organisation and any risk assessments that have been performed - For each objective, the organisation should establish: The activities and resources, responsibilities, timelines, and results required to achieve the objective - At a minimum, the organisation should establish, make available, and document the following resources: the required competencies of individuals who have an influence on the performance of the ISMS, awareness of their contribution to this and the consequences of not meeting the requirements of the ISMS, communication (about what, when, to whom, and how), documented information (design, control, approval, and updating). - Information security objectives should be documented, communicated, and kept up to date **Definitions** **ISMS:** Information Security Management System
The organisation understands the internal and external context in which it operates and its scope of information security. **Requirements** * The organisation should identify external and internal key issues that are relevant to its purpose and that affect its ability to achieve the intended results of its information security management system (ISMS). * The organisation should further determine which stakeholders are relevant to the management system, and which requirements of these stakeholders are relevant to information security * The organisation profile provides guidance for risk analysis and determining measures to mitigate risks. * The organisation profile should be documented and kept up to date.
Management should regularly review and evaluate the suitability, adequacy and effectiveness of the ISMS. **Requirements** - Management should consider: a) the status of actions resulting from previous management reviews; b) changes in external and internal issues relevant to the ISMS; c) changes in needs and expectations of stakeholder relevant to the ISMS; d) feedback on information security performance; e) stakeholder feedback; f) results of risk assessments and risk treatment status; and g) opportunities for continual improvement - The management review should be conducted at planned intervals, and results documented. **Definitions** **ISMS:** Information Security Management System.
Log files are protected against unauthorised modification. **Requirements** - Log files should be secured in such a way that no user is able to modify, delete, or otherwise manipulate the log of their own activities.
Networks, systems and applications should be monitored for abnormal behaviour and appropriate measures should be taken to evaluate potential information security incidents. **Requirements** - The monitoring system should be configured based on the established baseline (see logging & monitoring policy) to identify abnormal behaviour, to report on it and to minimize false positives. - When using cloud services, it should be clear which party is responsible for (configuring) monitoring systems and following up on deviations. - Monitoring should be done in real-time or at regular intervals, depending on the needs and possibilities of the organisation.
Log files recording activities, exceptions, errors and other relevant events should be produced, stored, secured and analysed. **Requirements** - Logging should be in line with the logging & monitoring policy. - Log files should contain the following information: user identifications, system activities, dates/times and details of relevant events, identity of assets and their (virtual) location, network addresses and protocols. - To help identify important events for information security monitoring, the use of appropriate system tools or auditing tools for querying records may be considered (e.g. IDS, SIEM). **Definitions** **IDS:** Intrusion Detection System **SIEM:** Security Information and Event Management
The capacity and performance of assets (e.g. systems, applications and services) are continuously monitored to ensure that current and anticipated future capacity requirements are met. **Requirements** * Performance monitoring should be set up in line with requirements identified during the business impact analysis (BIA) and/or business continuity planning (BCP). * Measures should be in place to identify and monitor capacity issues. * Management should use this information to identify and prevent challenges and dependencies. **Definitions** **Resources:** These are the resources that the company has at its disposal to deliver services and products. Systems, applications and services are assets, but so are physical locations, personnel and budget.
Rules and procedures for producing logs of activities, exceptions, errors and other relevant (information security) events are defined and implemented. **Requirements** - The policy should contain for each activity (where applicable): user IDs, system activities, date and time, activity details, system identifiers, and network addresses and protocols - The organisation should consider logging the following: successful and denied attempts to gain access to systems and other sources of information, system configuration changes, the use of privileges and system resources, the creation, modification and/or deletion of critical data and identities, alarms from security systems, the activation and deactivation of security systems, and transactions performed in applications. - The organisation should establish a baseline for normal behaviour and indicators of abnormal behaviour. - The policy should be documented and kept up to date.
Internal audits are planned systematically and periodically with a frequency and scope appropriate to the organisation's risk profile. **Requirements** - The internal audit plan should include the timing, audit criteria, scope of the audit, and the auditors selected (so that the audit process can be conducted objectively and independently). - Audits that assess operational systems should be planned and approved jointly by the auditor and relevant management to minimise the impact of the audit on operational systems and business processes. - The audit plan should also take into account the significance of the processes involved and the results of previous audits. - Internal audit plans should be documented and kept up to date. **Definitions** **Internal audit:** An objective and independent assessment of the extent to which the organisation complies with internal or external requirements, and the effectiveness of the implementation and maintenance of these by the organisation itself (e.g. the compliance function).
The organisation responds to nonconformities by taking action to analyse and correct them. **Requirements** - Management should respond to nonconformities by taking action to control and correct them, or by addressing their consequences. - Management should evaluate the need to take action to eliminate the causes of nonconformities; - Management should implement all necessary actions and evaluate the effectiveness of those actions. - Management should make changes to the ISMS as necessary; - The nature of nonconformities, the actions taken, and the results thereof should be documented. **Definitions** **ISMS:** Information Security Management System.
Rules and procedures for planning, conducting and reporting internal audits are defined and documented in the internal audit programme. **Requirements** - The internal audit programme should include the frequency, methods, responsibilities, and planning and reporting requirements of internal audits. - The internal audit programme should be documented and kept up to date. **Definitions** **Internal audit:** An objective and independent assessment of the extent to which the organisation complies with internal or external requirements, and the effectiveness of the implementation and maintenance of these by the organisation itself (e.g. the compliance function).
The organisation should identify which legal, statutory, regulatory, and contractual requirements are relevant to information security and privacy. **Requirements** - This information should be documented and kept up to date.
Software projects, including their information security requirements, are managed and monitored throughout the software development lifecycle. **Requirements** - The organisation identifies, assesses, monitors, and reports on security risks for products or services to be delivered by projects. - The organisation defines and assigns information security responsibilities and authorities relevant to the project to specified roles. - When selecting a development platform (including development tools and environments), the organisation should consider the following: the extent to which the software supports project development (such as project tracking, roles and responsibilities, milestones, priorities, project monitoring, and progress reporting), secure storage and processing of software code, configuration options, and functionality that allows code to be developed and tested securely.
Development, test, and production environments are logically or physically separated to protect the production environment from the risks of development and testing activities. **Requirements** - The organisation should consider: the necessary degree of separation (logical or physical), what activities are performed in each environment, rules and procedures for transporting software code between environments, access restrictions and segregation of duties, monitoring and backups, and minimising or masking of live data in development and test environments.
Software, whether purchased or developed, should be thoroughly tested before it is put into production. The extent of testing should be proportionate to the importance, the nature of the system and the potential impact of the change being introduced. **Requirements** - The developed source code should be tested during and after development. This can be done by means of vulnerability scanning (SAST). - The organisation should consider writing test plans. Test plans should be determined using a range of criteria, including security and privacy considerations. - Used libraries should be regularly scanned for information security issues and known vulnerabilities (Software Composition Analysis or SCA). The results should be evaluated and action taken if necessary. - The organisation should consider having the software code reviewed by someone other than the developer before it is put into production (4-eye principle, or peer review). Peer reviews should assess the quality of the source code, compliance with secure software development policies, use of required development environments, platforms and tools, adequate testing and documentation, and follow-up of identified vulnerabilities.
A secure system architecture is designed and implemented for products and services developed or acquired by the organisation. Information security risks and requirements are identified, implemented, and monitored throughout the software development lifecycle. **Requirements** - The organisation performs activities such as concept exploration, analysis of alternatives, and preliminary or applied research to refine the concepts and/or feasibility of technologies used in a new system. - The organisation defines information security and privacy requirements for products or services to be delivered by the project using various methods and inputs, such as information security policy, regulatory requirements, threat modelling, incident reviews, and the use of vulnerability thresholds or contingency planning. - The architecture should consider any assumptions about - and dependencies on - external systems and services; - This effort is initiated during the concept and development phases of the system lifecycle
Operational data used in development and test environments should be appropriately selected, protected, and managed. **Requirements** - The organisation should secure test information in accordance with the information classification and management policy and relevant laws and regulations, such as by limiting the use of (sensitive) (personal) data, securing access to development and test environments, logging & monitoring, and masking and/or anonymising data where necessary. - Live data should be removed from the test environment immediately after testing has been completed, if possible.
When developing software, secure coding principles should be applied to ensure that the number of potential information security vulnerabilities in the software is reduced. **Requirements** - When analysing the source code, the organisation should consider the following: level of adherence to programming standards and practices, readability of the code, use of insecure constructs and functions, opportunities to reduce the attack surface, and consideration of the most common programming errors and vulnerabilities in the source code (e.g. OWASP top 10). - The organisation should consider separating application secrets (passwords, API keys, SSH keys, and digital certificates) from the source code (e.g. in environment variables or in a key vault), to prevent theft of authentication credentials via the application source code. - The organisation should consider the following issues regarding the use of external libraries and tools: popularity, actively managed including regular updates, secure history and reputation, from trusted sources, availability of development sources for future management and maintenance. **Definitions** **Application Secret:** This is information that should be kept secret, such as passwords, API keys, SSH keys, and digital certificates. **Code Linter:** A tool that programmatically scans source code with the goal of identifying potential problems early. Code linters are strong in identifying stylistic errors, suspicious constructions, and bugs. **IDE:** Integrated Development Environment **SAST:** Static testing for application security. A SAST tool programmatically scans source code with the goal of identifying potential vulnerabilities early. SAST tools are strong in identifying the use of poorly secured access methods and opportunities to reduce the attack surface (e.g., analysis of duplicate source code and unused functions).
Rules and procedures for the secure design and development of software and systems are defined and implemented. **Requirements** - The organisation should consider explanation of, and principles and requirements for: secure system and software architecture, design and development, separation of development, test, and production environments, security (checkpoints) in projects, security testing (regression testing, code scans, and penetration tests), secure storage of source code, version control, necessary security knowledge and training, developer skills in preventing, discovering, and preventing or remediating vulnerabilities and licensing issues. - Secure design rules should take into account: threat modelling, the need for integration with a security architecture, technical security infrastructure (e.g. access restrictions, data protection), the organisation's ability to develop and support the technology, the cost, time and complexity of implementing measures, good practices such as "secure by design" and "zero trust", an assessment of the design for information security, and the need for system hardening. - Secure development policies should take into account: the use of a secure development environment (IDE), tools, standards, methods, and techniques (and prohibition of insecure versions thereof), testing (SAST, DAST), reducing the attack surface, reviews, secure maintenance, use of secure and up-to-date external tools and programming code (e.g. libraries) - The organisation should assess the information security risks of designing and developing software and systems as part of the policy (and/or per project) and define and implement necessary measures. - The policy should be documented, communicated, and kept up to date.
Software and firmware are kept up to date to ensure that the latest approved patches and application updates are installed for all approved software. **Requirements** * The organisation should implement patch management in line with the requirements of the change policy. * For purchased software, facilities to automatically deploy updates should be considered. * For cloud software, patch management should be contractually enforced by the vendor. * The organisation should consider alternative measures when an unacceptable software vulnerability is identified for which no update is available or can be installed (e.g., disabling services, isolating software, modifying firewalls, etc.)
Technology is used to detect and remove malicious software (malware). **Requirements** - It should be determined where the application of anti-malware technology will have the most effect; in application protocols such as email, file transfer, and the web, and/or in user endpoint devices (e.g. laptops) and servers - Anti-malware software should be updated regularly, and the monitored information assets should be scanned regularly. **Definitions** **Malware:** Software used to disrupt computer systems, gather sensitive information, or gain access to private computer systems. Derived from 'malicious software'
Information is gathered and acted upon on existing or emerging threats and vulnerabilities of deployed information systems and the organisation's exposure to these threats and vulnerabilities. **Requirements** - The organisation should obtain a clear understanding and situational awareness of evolving threats and attacker tactics in the current threat landscape (and their potential impact on the business), sharing strategic, tactical, and operational threat information as appropriate, and using it to support strategic decision-making, risk assessment, and resource allocation. - The organisation should establish and maintain contact with special interest groups or other specialized security forums and professional associations. - It is recommended to use additional sources of information, preferably independent vendors or consultants, government agencies, or groups that collectively gather and analyse threat information. - It is recommended to determine the source(s) of information used to identify vulnerabilities for each relevant asset. - It is recommended to use technologies to collect vulnerabilities and evaluate their relevance to assets in use by the organisation. - The organisation should analyse the information gathered and use it as input into processes that address vulnerabilities (e.g., incident response, software updates, anti-malware, and configuration management). - The list of information sources and other methods to identify vulnerabilities should be documented and kept up to date.
Known vulnerabilities in deployed software and hardware are identified, evaluated, and remedied using a vulnerability management system. **Requirements** - It is recommended to use technologies that are able to: a) collect known vulnerabilities; b) scan assets (servers, virtual machines, e-mail servers, developed or purchased (web) applications) for the presence of these vulnerabilities, e.g. using DAST; and c) implement or propose solutions (patches or compensating measures). **Definitions** **Dynamic Application Security Testing (DAST):** A process of testing a (web) application in a running state to find security vulnerabilities (as opposed to SAST, which is performed on the source code). DAST tools analyse programs while they are running to detect security issues such as memory corruption, unsafe configuration, cross-site scripting, user privilege issues, SQL injection, and other critical security issues.
Rules and procedures for coordinated vulnerability disclosure are defined and implemented so that security researchers and others are able to report issues. **Requirements** - The policy should provide procedures for reporting vulnerabilities, a public point of contact, and methods for reporting issues (e.g., reporting forms or forums) - The policy should be documented, communicated, and kept up to date.
Authentication technologies and procedures are selected and implemented based on information security requirements. **Requirements** - Authentication methods should be consistent with the access control policy and appropriate for the classification of information being accessed. - Access to privileged identities (e.g., admin user) and critical information systems should be secured using authentication methods stronger than passwords (e.g., digital certificates) or the use of multiple authentication factors (multifactor authentication). **Definitions** **Authentication:** The process of verifying the identity of the user or service requesting access to protected information or systems.
Identities and access rights for employees and other stakeholders are allocated in accordance with the access control policy. **Requirements** - Identities and access rights should be traceable to a single person to the greatest extent possible to ensure traceability and individual accountability for actions taken by the individual. - Identities and access rights should only be granted after authorisation by the information (asset) owner and/or management, and revoked when access is no longer required. - Privileged and non-personal identities and access rights (e.g. privileged, group and service accounts) should only be granted when necessary and after special approval, be subject to independent logging, monitoring and regular review, and be deactivated or deleted in a timely manner. - A central record of access rights assigned to user identification should be maintained, including a record of changes to user access rights.
Rules and procedures for logical and physical access to information and other related assets are defined and implemented. **Requirements** - The policy must be established by owners of information (assets) - The policy must describe for whom (which identities), for which type of information (classifications), and for which assets (applications, physical, etc.) which access security is required. - The policy must describe on which principles access is based. It is recommended to use at least the following principles: 'need-to-know', 'need-to-use', 'least privilege' and 'segregation of duties' - The policy must include rules and procedures for the registration, approval, assignment, management, and revocation of authentication information (including cryptographic keys), identities and access rights (including special and non-personal identities and access rights). - The policy must be consistent with internal and external requirements and other provisions in the ISMS. - The policy must be documented, published, communicated, and kept up to date. **Definitions** **ISMS:** Information Security Management System.
Roles, responsibilities, and authorities for information security and privacy are assigned and communicated within the organisation. **Requirements** * At a minimum, management should describe and assign the following responsibilities and authorities to individuals in the organisation: oversight of the ISMS (and reporting its performance to management), technical management of networks, systems, and applications, technical management of vulnerabilities (monitoring, risk assessment, updates, asset tracking, and coordination), and coordination of incidents and disruptions including communications. * The organisation should document and communicate roles and responsibilities to relevant internal and external stakeholders. * The organisation should check competency of their employees.
Access rights are reviewed periodically and adjusted or removed if necessary (user access review). **Requirements** - Physical and logical access rights should be reviewed regularly, with attention to the following aspects: privileged access rights (such as admin accounts, high-privilege system accounts, and other "privileged access"), non-personal identities (e.g. shared credentials, group accounts), and the access rights of users after a change of role within the organisation or termination of employment.
Stored data is appropriately encrypted to ensure data integrity and confidentiality. **Requirements** - Encryption of stored data should be in accordance with the requirements of the secure baseline configuration and cryptographic key management policy (see access control policy )
Where the protection of sensitive data (e.g. personal data) is a concern, the organisation should consider hiding such data using techniques such as data masking, pseudonymisation, or anonymisation. **Requirements** * The organisation should identify and categorise sensitive data that requires masking to meet legal, statutory, regulatory, and contractual requirements. * The organisation should implement appropriate data masking techniques based on the sensitivity and use case of the data. * Masking techniques should be applied consistently across production, test, and development environments. * Data masking procedures should be regularly reviewed and updated to address new risks or changes in data processing.
The organisation maintains a register for the processing of data under its responsibility. **Requirements** - The organisation should establish records of processing activities when it processes personal data on a structural basis (which is almost always the case), processes personal data that pose a high risk to the rights and freedoms of data subjects, processes special personal data or criminal information, or when it employs more than 250 employees. - The records of processing activities should contain the following information (where relevant and possible): name and contact details of the organisation, data protection officer (DPO), and other relevant organisations; the purpose of the data processing, a description of the individuals whose data are processed, a description of the type of data, the date on which the data should be erased, with which organisations the personal data are shared and whether these are organisations outside the EU, and the measures that the organisation takes to secure the personal data. - The records of processing activities should be documented and kept up to date. **Definitions** **Data protection officer (DPO):** The employee responsible for ensuring secure data processing.
Where the protection of sensitive data (e.g., personal data) is a concern, the organisation should consider deploying a technology that helps prevent data leakage. **Requirements** - The organisation should identify and categorise sensitive data that requires the implementation of a data leakage prevention technology to meet legal, statutory, regulatory, and contractual requirements. - The organisation should then deploy it on systems, networks, and other devices on or through which the sensitive information is processed, stored, or transported. - The organisation should consider the following tools: a) Identifying which sensitive information is at risk of unauthorised disclosure (e.g., in unstructured data on a user's system); b) Detecting disclosure of sensitive information (e.g., when information is uploaded to untrusted third-party cloud services or sent via email); c) blocking user actions or network transmissions that expose sensitive information (e.g. uploading or downloading files to or from cloud services, copying data to a spreadsheet, using portable storage devices, taking screenshots). - Monitoring of staff communications and online activities should be in accordance with applicable guidelines and laws and regulations (e.g. privacy laws).
Rules and procedures for classifying and managing information based on its importance to the organisation are defined and implemented. **Requirements** - The policy should describe how and when information should be classified and labelled (it is recommended to apply labels only above a certain level, either in headers and footers or in metadata of digital information), at what level labels should be applied (this can be per document, but also per information asset), what requirements apply per classification (distribution restrictions, distribution rules, secure processing and transfer, masking or anonymisation, retention, and backup), and when the classification of information should be reassessed. - The classification scheme should take into account - and the levels should be based on - the requirements for availability, integrity, and confidentiality (AIC) of information, resulting from business necessity, applicable laws and regulations, and relevant internal and external parties. - The policy should be documented, communicated, and kept up to date.
Transmitted data is appropriately encrypted to ensure data integrity and confidentiality. **Requirements** - Encryption of data in transit should comply with the requirements of the secure baseline configuration and cryptographic key management policy (see access control policy)
Rules and procedures for the secure - and in accordance with laws and regulations - collection, storage, retention and deletion of personal data are defined and implemented. **Requirements** - The GDPR requires that individuals whose personal data the organisation processes are properly informed about the processing of their personal data. As a rule, organisations publish a privacy statement (privacy notice) on the website for this purpose. The organisation may choose to combine the privacy policy and the privacy statement and publish them as one. - The policy should be documented, communicated and kept up to date.
Information is classified, labelled, and managed in accordance with the information classification and management policy. **Requirements** - The organisation should periodically determine that information, in accordance with the information classification and management policy: a) is (appropriately) classified and labelled, e.g., by means of a business impact analysis for all information and information assets; b) is processed in accordance with the requirements arising from the classification (e.g., restriction of access and distribution, secure processing and transfer, masking or anonymisation, retention, encryption, and back-up). - The organisation should identify and make available documentation that the organisation considers necessary for the effectiveness of the information security management system.
The organisation establishes and maintains retention periods and disposal times of information assets to meet legal, regulatory, and business requirements. **Requirements** - The organisation must define retention periods for different types of information. - The organisation must ensure retention practices comply with relevant legal and regulatory requirements.
Information security events are assessed and a decision is made as to whether they should be categorised as information security incidents. **Requirements** - Information security events are assessed and categorised and prioritised according to established criteria in accordance with the incident response plan. - Results of the assessment and decision should be recorded in detail for future reference and verification. - The organisation should identify, collect, obtain and preserve evidence relating to information security events. - The organisation should be able to demonstrate that: incident records and evidence are complete and not tampered with, copies match originals, and information systems were operating properly at the time evidence was recorded. - Early involvement of legal or law enforcement authorities is recommended where violations of law are suspected, to prevent deliberate or accidental removal of evidence.
An information security incident response plan is defined and implemented. **Requirements** - The organisation should establish processes for: a) assessing information security events and recording the outcomes. b) identifying, reporting, recording, classifying, prioritising, analysing, communicating, coordinating, evaluating, remediating, reporting and learning from incidents. c) identifying, collecting, obtaining and preserving evidence related to information security events. - The processes should be documented and kept up to date.
Incidents are adequately resolved, reported, and evaluated to limit impact, maintain or restore services, and prevent future incidents. **Requirements** - Incidents are resolved and reported in accordance with the incident response plan - Significant and disruptive incidents are reported without delay to management and external agencies in accordance with applicable laws and regulations. - Lessons learned from information security incidents should be used to strengthen and improve information security controls.
A business impact analysis should be performed to assess the impact over time as a result of the disruption to business activities delivering products and services. **Requirements** - The business impact analysis (BIA) should result in a classification per relevant asset and use impact types (e.g. financial impact, operational impact) and criteria (availability, integrity, confidentiality) to assess the impact (with magnitude and duration) for the organisation and business activities delivering products and services. - For the purpose of continuity policy, a recovery time objective (RTO) should be assigned to assets with (high) availability requirements in the BIA. The BIA can be extended by assigning performance requirements (e.g. MASL) and data recovery time point (RPO). **Definitions** **MASL:** Minimum Acceptable Service Level **RPO:** Recovery Point Objective **RTO:** Recovery Time Objective
Strategies and plans for maintaining, recovering, and securing service provision during disruptions are defined and implemented. **Requirements** - The business continuity plan should include: a) availability requirements for information assets (e.g., RTO, RPO, MASL), or derived from a performed business impact analysis (BIA); b) controls to maintain availability in accordance with the requirements (e.g., regular back-ups of information and redundancy of information processing facilities); c) processes to maintain those controls during a disruption; and d) compensating measures where this is not possible. e) regular evaluation of the plan through exercises and disaster recovery tests. The frequency and depth of these tests will depend on the organisation's risk profile and the complexity of IT systems. - The organisation should establish a backup policy that considers the following: accurate and complete backups, documented recovery procedures, performance in accordance with business requirements (RTO and RPO), secure storage of backups, encryption of backups, and retention of backups, taking into account information policies and relevant laws and regulations. - The policy should be documented, approved (by management), and kept current. **Definitions** **MASL:** Minimum Acceptable Service Level **RPO:** Recovery Point Objective **RTO:** Recovery Time Objective
Disaster recovery testing is performed periodically. **Requirements** - The organisation should periodically determine whether availability or recovery of business processes is possible in accordance with the requirements of the business continuity plan. **Definitions** **Disaster recovery testing:** An exercise performed to validate the effectiveness of the business continuity plan and identify areas for improvement. Testing may include simulations of various scenarios to assess an organisation's preparedness and improve its response capabilities, and, where applicable, the transition of critical business functions, supporting processes, and information assets to the disaster recovery environment.
Backups of information, software and systems are made and maintained to enable recovery of data or systems in the event of loss. **Requirements** - The organisation should make backups of data and information systems in accordance with the business continuity plan.
User endpoint devices (incl. mobile devices) are enrolled and monitored in an endpoint management solution (e.g. an MDM). **Requirements** - All endpoint devices used by employees to process or access company information are enrolled in an endpoint management solution (e.g. an MDM system) - User endpoints should be periodically security assessed to ensure they conform to secure baseline configurations. **Definitions** **User endpoint device:** Any device that stores or processes information (e.g. laptops, mobile devices), whether owned by the organisation or personally owned and used on behalf of the organisation [bring your own device (BYOD)]. **MDM:** Mobile device management. A system that organisations use to manage and maintain mobile devices. These can be laptops or phones, but today some MDMs can also manage virtual machines and IoT devices.
A secure network architecture has been defined and implemented for networks and network devices (e.g. routers), including a description of where networks and information flows are logically or physically separated (segmented). **Requirements** - The organisation should establish a secure network architecture for networks and network devices that takes into account the following: the type and level of information classification that the network can support, management responsibilities and procedures, separation of operational responsibilities for networks and systems, measures for securing public and wireless networks, logging & monitoring of network events, and coordination of network management activities. - Network diagrams and device configuration files should be documented and kept up to date.
Configurations, including security configurations, of hardware, software, services, and networks should be established and managed. **Requirements** - The organisation should define standard configurations that are: based on publicly available guidelines (e.g., vendor or security organisation system hardening guidelines), provide an adequate level of security (for the type and classification of the asset), support the ISMS, and are feasible and appropriate for the organisation. - Examples of standard configurations include: minimising access identities and privileged access, limiting unnecessary functions and services, clock synchronisation, and verifying compliance with license requirements. - It is recommended that infrastructure as code or other configuration automation techniques be used where possible. - The standard configurations should be documented, implemented, monitored, regularly reviewed, and kept up to date. **Definitions** **ISMS:** Information Security Management System.
Groups of information services, users, and information systems are logically or physically separated from each other (segmented). **Requirements** - Groups of information services, users, and information systems (e.g., virtual machines, WANs, and wi-fi networks) should be defined and separated from each other in the organisational network. This can be done by information security criteria (e.g., public domain, desktop domain, server domain, low-risk or high-risk systems), organisational departments (e.g., human resources, finance, marketing), or a combination of both. - Network boundaries, and in particular the external boundaries of each domain and with the Internet, should be defined and governed by a gateway (e.g., firewall). - Wireless access networks for guests should be separated from those for staff.
Compliance with agreements is monitored, including service level performance and changes made by vendors. **Requirements** - Monitoring may include: reviewing reports by vendors (service level reports), consulting with vendors (and/or relationships with its own vendors), identifying and evaluating vulnerabilities and incidents, reviewing audit reports or certifications performed by third parties (e.g. ISO27001, SOC1/2/3, ISAE3402), or performing audits itself. - The organisation should conduct regular vendor assessments, and update controls or agreements as necessary.
Rules and procedures for managing information security risks associated with the use of products and services provided by vendors are defined and implemented. **Requirements** * The organisation should describe in this document the processes and procedures that the organisation requires the vendor to implement in order to commence (or cease) use of a vendor's products or services. * The organisation should also describe in this document the following processes and procedures that it implements itself, including: a) identifying and documenting the types of vendors, products and services that may pose an information security risk, including how they are subsequently evaluated and selected; b) selecting only vendors, products and services with low risk, adequate information security controls, or adequate compensating measures; c) managing risks caused by the vendor's use of the organisation's information and other assets, and by vulnerabilities or disruptions in products and services provided; d) monitoring each type of vendor and each type of access, and taking action where vendors do not meet information security requirements; e) dealing with incidents and emergencies f) requirements for personnel of the own organisation and that of the vendor g) safely terminating vendor relationships. * The policy should also be applied to cloud service providers, when outsourcing development work, and imposed on the entire ICT supply chain of vendors. * The policy should be documented, communicated, and kept up to date. **Definitions** **Information security risk:** A risk that, if it occurs, could have an impact on the availability, integrity, and/or confidentiality (AIC) of information of the organisation
All individuals who enter into employment (full, part, and/or temporary) are screened prior to commencement of employment. **Requirements** - Screening should be proportionate to the business requirements, the classification of information the individual will have access to, and the identified risks. - The following screening activities should be considered, and carried out depending on the criticality of the candidate's role and access: business and personal references, curriculum vitae check, confirmation of claimed academic and professional qualifications, independent identity checks (e.g. passport), and more detailed checks (e.g. credit checks or criminal records). - Screening should be carried out in accordance with all relevant privacy requirements and applicable employment laws - For contract staff, screening requirements should be included in vendor contracts. - Screening should be carried out on promotion and periodically, depending on the criticality of an individual's role and access.
Employees should be appropriately educated and trained in information security and relevant aspects of the ISMS, as relevant to their role. **Requirements** - The organisation should establish an information security awareness program, education and training in accordance with the ISMS, which should include the following aspects: awareness activities, management involvement in information security, the need to be aware of and comply with applicable rules and requirements, personal responsibility in this regard, basic measures such as incident reporting and password protection, contact points and sources for additional information, guidance, and materials, and a final evaluation or assessment of understanding. - The awareness program should (preferably): take into account the roles of personnel (including internal and external personnel), be conducted regularly and on a staggered basis, and build on lessons learned from information security incidents. - For technical teams with roles that require specific skills and expertise, the organisation should establish, prepare, and implement an appropriate training plan. - Employees should be trained periodically and, where necessary, when the role description changes. **Definitions** **ISMS:** Information Security Management System.
Employment contracts should specify the responsibilities of personnel and the organisation with regard to information security. **Requirements** - The organisation should ensure that personnel and contractors agree to terms and conditions regarding information security. - These terms and conditions should include the information security policy (including relevant policies on specific topics) and should be appropriate to the nature and extent of access they will have to (ISMS-relevant) company resources. - The following points should be addressed where relevant: confidentiality agreements (NDAs), legal responsibilities and rights (e.g. over intellectual property), responsibilities for information received, and disciplinary measures. - The organisation should ensure that personnel and contractors agree to these terms and conditions. - The information security terms and conditions should be reviewed when laws, regulations, information security policies or topic-specific policies change. **Definitions** **ISMS:** Information Security Management System.
Rules and procedures for the acceptable (and unacceptable) use of information and other assets are established and implemented. **Requirements** - The policies should describe the responsibilities of employees for handling information to which they have access, and assets in their possession. They should clearly describe what uses are acceptable and what uses are unacceptable, including a disciplinary procedure for breaches of information security. - Each employee (including any other stakeholder) should acknowledge that he/she understands the rules and procedures and agrees to comply with the policy where applicable. - The organisation should consider granting access to company information only after the policy has been acknowledged by the employee or other stakeholder. - The rules and procedures should be documented, published, communicated, and kept up to date.
Rules and procedures for securely changing and updating information systems are defined and implemented. **Requirements** - The policy should apply to the implementation of new software and systems, major changes to existing software and systems, configuration changes, and (major) software updates (also for purchased software). - The policy should include the following: impact assessment, planning, authorisation, communication, testing, approval, implementation, and documentation of changes, emergency changes, fall-back scenarios, and updating continuity plans where necessary and applicable. - The policy should be documented and kept up to date.
An inventory of information and other related assets that support the organisation's business functions and processes is established and maintained. **Requirements** - The inventory should include the following for each asset or group of assets: name, owner (an individual or group), classification (see business impact analysis), and, where applicable, vendor, version number, location, and relationship to other internal and external systems and processes - The inventory may be divided into several lists and therefore does not have to be in one location. - The level of granularity of the inventory of information and other related assets should be appropriate to the needs of the organisation. - The inventory should be documented, accurate, current, consistent, and in line with other inventory records.
Third parties this organization works with that may process customer data.
Cloud infrastructure provider hosting the Triagen platform. Provides compute (Cloud Run, GKE), data (Cloud SQL for PostgreSQL), storage (Cloud Storage, Artifact Registry), networking (VPC, Cloud CDN, Cloud Armor), identity (IAM, Workload Identity Federation), secrets (Secret Manager), and audit logging (Cloud Logging, Cloud Audit Logs). Production region: europe-west4 (Eemshaven, NL).
Transactional email and email-delivery service used by the Triagen platform for system-generated email (e.g. feedback notifications). EU-based provider.
External identity provider for the Triagen platform, served from the auth.triagen.ai custom domain. Handles end-user and operator authentication. Owned and operated by Okta Inc.