From a7cd8cddd3ce6bc1032b867ef2f732538116f99f Mon Sep 17 00:00:00 2001 From: Eric Bariaux <375613+ebariaux@users.noreply.github.com> Date: Tue, 5 May 2026 15:29:18 +0200 Subject: [PATCH 1/6] Import of current Google doc as markdown files --- .../annex-a-statement-of-applicability.md | 54 +++++++++++ .../annex-b-incident-response-templates.md | 7 ++ docs/annexes/index.md | 7 ++ ...s-continuity-and-operational-resilience.md | 52 +++++++++++ docs/continuous-improvement.md | 31 +++++++ docs/core-operational-processes.md | 43 +++++++++ .../data-protection-and-privacy-management.md | 23 +++++ docs/evidence-register-tools-and-systems.md | 90 +++++++++++++++++++ ...incident-management-and-nis2-compliance.md | 23 +++++ .../information-security-management-system.md | 28 ++++++ docs/introduction.md | 22 ++++- ...-security-and-infrastructure-protection.md | 35 ++++++++ docs/organisational-context-governance.md | 37 ++++++++ docs/people-resource-management.md | 27 ++++++ ...erformance-evaluation-and-retrospective.md | 25 ++++++ docs/risk-management-framework.md | 34 +++++++ docs/secure-product-development-lifecycle.md | 44 +++++++++ ...y-chain-and-third-party-risk-management.md | 21 +++++ ...y-management-and-coordinated-disclosure.md | 29 ++++++ sidebars.ts | 27 ++++++ 20 files changed, 658 insertions(+), 1 deletion(-) create mode 100644 docs/annexes/annex-a-statement-of-applicability.md create mode 100644 docs/annexes/annex-b-incident-response-templates.md create mode 100644 docs/annexes/index.md create mode 100644 docs/business-continuity-and-operational-resilience.md create mode 100644 docs/continuous-improvement.md create mode 100644 docs/core-operational-processes.md create mode 100644 docs/data-protection-and-privacy-management.md create mode 100644 docs/evidence-register-tools-and-systems.md create mode 100644 docs/incident-management-and-nis2-compliance.md create mode 100644 docs/information-security-management-system.md create mode 100644 docs/operational-security-and-infrastructure-protection.md create mode 100644 docs/organisational-context-governance.md create mode 100644 docs/people-resource-management.md create mode 100644 docs/performance-evaluation-and-retrospective.md create mode 100644 docs/risk-management-framework.md create mode 100644 docs/secure-product-development-lifecycle.md create mode 100644 docs/supply-chain-and-third-party-risk-management.md create mode 100644 docs/vulnerability-management-and-coordinated-disclosure.md diff --git a/docs/annexes/annex-a-statement-of-applicability.md b/docs/annexes/annex-a-statement-of-applicability.md new file mode 100644 index 0000000..82d7e4c --- /dev/null +++ b/docs/annexes/annex-a-statement-of-applicability.md @@ -0,0 +1,54 @@ +--- +sidebar_position: 1 +--- + +# Annex A. Statement of Applicability and mapping ISO27001, NIS2 and CRA + +This annex contains the official Statement of Applicability for OpenRemote. It lists + +- The relevant ISO27001 security controls and describes how they are implemented within the organisation as described in this handbook. +- A mapping between the security requirements of the NIS2 Directive and the controls implemented by OpenRemote as described in this handbook. +- The cybersecurity requirements of the Cyber Resilience Act to the secure development and vulnerability management processes described in this handbook. + +| Security Domain | ISO27001 Annex A | NIS2 Art.21 | CRA Requirement | OpenRemote Handbook Chapter | +| ----- | ----- | ----- | ----- | ----- | +| Governance & Security Policy | A.5.1 Policies for information security | Risk management measures | Secure-by-design governance | 1.3, 2.2, 2.3 | +| Roles and Responsibilities | A.5.2 Information security roles | Governance responsibility | Organisational accountability | 2.3 | +| Information Security Management | A.5.1–A.5.7 | Cybersecurity risk management | Security lifecycle governance | Chapter 3 | +| Risk Management | A.5.7 Threat intelligence / risk mgmt | Risk management measures | Risk management in design | Chapter 4 | +| Asset Management | A.5.9 Inventory of information assets | Asset identification | Asset transparency | 4.2 | +| Access Control | A.5.15 Access control | Access control measures | Secure configuration | 7.3, 16.3 | +| Authentication | A.5.17 Authentication information | Identity management | Secure access | 7.3 | +| Logging & Monitoring | A.8.15 Logging | Monitoring and detection | Monitoring mechanisms | 7.4 | +| Change Management | A.8.32 Change management | Security in operations | Secure lifecycle management | 7.5 | +| Secure Development | A.8.25 Secure development lifecycle | Security in development | Secure-by-design development | Chapter 5 | +| Secure Coding | A.8.28 Secure coding | Secure development practices | Secure software development | 5.3 | +| Build & CI/CD Security | A.8.27 Secure system engineering | Development security | Software integrity controls | 5.4 | +| Software Bill of Materials | A.8.9 Configuration management | Supply chain risk | Component transparency | 5.5 | +| Product Lifecycle & Support | A.8.31 Separation of dev/test/prod | Lifecycle security | Update and maintenance obligations | 5.6 | +| Vulnerability Monitoring | A.5.7 Threat intelligence | Vulnerability handling | Vulnerability monitoring | 6.1 | +| Patch Management | A.8.8 Management of technical vulnerabilities | Security updates | Timely patching | 6.2 | +| Vulnerability Disclosure | A.5.24 Information security incident reporting | Incident notification | Coordinated vulnerability disclosure | 6.3 | +| Security Advisories | A.5.26 Response to incidents | Incident communication | Security update communication | 6.4 | +| Infrastructure Security | A.8.20 Network security | Operational security | Secure infrastructure | Chapter 7 | +| Identity Management | A.5.16 Identity management | Access management | Secure authentication | 7.3 | +| System Monitoring | A.8.16 Monitoring activities | Threat detection | Security monitoring | 7.4 | +| Incident Management | A.5.25 Incident management | Incident handling | Incident response capability | 8.1 | +| Incident Reporting | A.5.26 Incident reporting | Incident reporting obligations | Security incident notification | 8.2 | +| Incident Review | A.5.27 Learning from incidents | Post-incident analysis | Continuous improvement | 8.3 | +| Business Continuity | A.5.29 ICT readiness for business continuity | Operational resilience | Service continuity | 9.1 | +| Disaster Recovery | A.5.30 ICT continuity | Service resilience | Recovery capabilities | 9.2 | +| Resilience Testing | A.5.30 Testing continuity | Resilience verification | Security testing | 9.3 | +| Supplier Risk Management | A.5.19 Supplier relationships | Supply chain security | Component supply chain security | Chapter 10 | +| Third Party Security | A.5.20 Security in supplier agreements | Supplier risk | Third-party risk control | 10.2 | +| Open Source Dependencies | A.8.9 Configuration management | Supply chain risk | Component risk monitoring | 10.3 | +| Data Protection | A.5.34 Privacy protection | Data protection obligations | Personal data protection | Chapter 11 | +| Data Classification | A.5.12 Classification of information | Information protection | Data security classification | 11.1 | +| Data Retention | A.5.33 Protection of records | Data governance | Secure data lifecycle | 11.2 | +| Data Subject Rights | GDPR support | Personal data protection | Privacy compliance | 11.3 | +| Security Awareness | A.6.3 Security awareness training | Human risk mitigation | Security awareness | 12.2 | +| Employee Offboarding | A.5.18 Access rights | Access lifecycle management | Secure staff transitions | 12.3 | +| Internal Audit | A.5.36 Compliance with policies | Security audits | Security evaluation | 14.2 | +| Management Review | A.5.35 Independent review | Governance oversight | Security governance | 14.3 | +| Continuous Improvement | A.10 Improvement | Continuous improvement | Lifecycle improvement | Chapter 15 | +| Tool Access Governance | A.5.15 Access control | System security | Access governance | 16.3 | diff --git a/docs/annexes/annex-b-incident-response-templates.md b/docs/annexes/annex-b-incident-response-templates.md new file mode 100644 index 0000000..63f0d62 --- /dev/null +++ b/docs/annexes/annex-b-incident-response-templates.md @@ -0,0 +1,7 @@ +--- +sidebar_position: 2 +--- + +# Annex B. Incident Response Templates + +This annex contains templates used during incident response activities, including incident reporting forms, communication templates, and post-incident review documents. diff --git a/docs/annexes/index.md b/docs/annexes/index.md new file mode 100644 index 0000000..78cee31 --- /dev/null +++ b/docs/annexes/index.md @@ -0,0 +1,7 @@ +--- +sidebar_position: 17 +--- + +# Annexes + +This section contains supporting annexes for the OpenRemote Quality Handbook. diff --git a/docs/business-continuity-and-operational-resilience.md b/docs/business-continuity-and-operational-resilience.md new file mode 100644 index 0000000..996904f --- /dev/null +++ b/docs/business-continuity-and-operational-resilience.md @@ -0,0 +1,52 @@ +--- +sidebar_position: 9 +--- + +# 9. Business Continuity and Operational Resilience + +## **9.1 Business Continuity** {#9.1-business-continuity} + +We currently have a high level description for our approach to business continuity and disaster recovery ([see section 16](./evidence-register-tools-and-systems)). + +## **9.2 Disaster Recovery Plan** {#9.2-disaster-recovery-plan} + +Regarding disaster recovery we have a disaster recovery plan in place for our main online services. For each of the services we are addressing the following items: + +**Disaster scenarios** +What could go wrong with this service? What could bring it down? + +**Impact** +What is the impact of the service being un-available, associated risk and probabilities this happens? + +**Access list** +Who has access to this service and with what level of permissions? Who could potentially take the whole service down? + +**Backups** +What is the current backup strategy for the service ? Where are backups stored ? How frequently are they performed? + +**Recovery process** +In case of a critical event, what would the process be to recover the service ? What does the service provider offer? How does that work? + +Our main services are + +* AWS +* Balena Cloud +* GitHub +* Google Workspace +* Bitwarden +* Website +* Domain +* Registries – NPM +* Registries – Maven +* Registries – DockerHub +* Slack +* Google Playstore +* Apple account + +The details and status of the disaster recovery plan is laid down in situation assessment which is continuously improved and described in [disaster recovery](https://docs.google.com/document/d/1zSvdKXf0o0t_39qCwqVoqNm4YByEAkhBjUL57YM8KMs/edit?usp=sharing). + +## **9.3 Resilience Testing – PLACEHOLDER** {#9.3-resilience-testing-–-placeholder} + +OpenRemote periodically tests the resilience of its systems and recovery procedures. Tests may include backup restoration, service failover simulations, or recovery exercises. + +The results of these tests are documented and used to improve resilience planning. diff --git a/docs/continuous-improvement.md b/docs/continuous-improvement.md new file mode 100644 index 0000000..408d70a --- /dev/null +++ b/docs/continuous-improvement.md @@ -0,0 +1,31 @@ +--- +sidebar_position: 15 +--- + +# 15. Continuous Improvement + +## **15.1 Corrective Actions** {#15.1-corrective-actions} + +Improvement actions are defined and followed up in three ways: + +First of all the KPIs are reviewed on a half yearly basis and targets are set and evaluated. The risk assessment approach is used to define the priority for improvement actions or mitigation plans. + +Secondly, on a half yearly basis, opportunities and threats are defined and translated into improvement actions. + +Finally, nonconformities are monitored on a weekly basis as part of the regular weekly meet-up and translated in- and followed up as corrective actions. + +The quality management system is audited by the management team on a yearly basis, leading to improvements of the processes as reflected in this handbook. + +If and when required key customers are invited to perform an audit on the quality management system. + +## **15.2 Preventive Actions** {#15.2-preventive-actions} + +Preventive actions are implemented when potential risks or weaknesses are identified, e.g. as part of vulnerability detections or performance evaluation, before they result in incidents or operational issues. + +These actions help strengthen the organisation’s resilience and operational reliability. + +## **15.3 Improvement Register** {#15.3-improvement-register} + +OpenRemote maintains a register of improvement actions derived from risk assessments, audits, or operational reviews reflected in the risk management register, quality KPIs and improvement, Data security and improvement, and sprint planning ([see section 16](./evidence-register-tools-and-systems)). + +These registers track the status of each improvement initiative and identify responsible owners. diff --git a/docs/core-operational-processes.md b/docs/core-operational-processes.md new file mode 100644 index 0000000..d7bbc3d --- /dev/null +++ b/docs/core-operational-processes.md @@ -0,0 +1,43 @@ +--- +sidebar_position: 13 +--- + +# 13. Core Operational Processes + +This chapter refers to the core operational processes: lead generation, project realisation, program management, human resource management and finance. + +## **13.1 Lead Generation** {#13.1-lead-generation} + +Via existing contacts, organised events, and social media, sales actively searches for new customer opportunities. The related network activities are based on personal preferences and skills. Future opportunities are sourced and evaluated based on strategic fit. + +Contacts become leads when the opportunity is considered feasible and a fit with the product or strategy, and balanced against the expected effort to turn them into a customer. Leads and opportunities are documented and managed via a CRM system. + +Leads and opportunities are translated into proposals, supported by a technical lead to validate a technically correct solution as much as possible in line with the product roadmap. Proposals are reviewed and negotiated with the lead. Related project proposals and relevant background information is gathered and stored in the project documentation storage. Before final submission to customers, proposals are reviewed with the management to evaluate feasibility, risks, margin towards product development, as well as the fit within the programming of projects and product. + +Customers who distribute the code commercially can agree on a commercial license. Pricing and deviations of the standard License agreement are dealt with as part of the project proposal + +## **13.2 Project Realisation** {#13.2-project-realisation} + +For project realisation, an agile approach is used with iterations based on issues as defined as part of roadmap, refinement and sprint planning (section 13.3) supported by a scrum based planning system. As part of realisation, automated system and unit tests are developed and included to safeguard code quality. + +Daily standups are organised in two rounds with the complete team, the first for each participant to share what he has worked on, will work on and raise impediments. The second round is to discuss impediments and possible resolutions. + +In the testing and review phase, code is tested on a local or staging environment, first by a colleague developer and project manager, secondly by the account manager and customer. Issues are tracked and solved, using the scrum system, and released in production. + +## **13.3 Roadmapping, refinement and sprint planning** {#13.3-roadmapping,-refinement-and-sprint-planning} + +The roadmapping is done as part of the half yearly cycle of reviewing product development and its programming. It maps long term business requirements from lead customers to product functional requirements. + +Project proposals for customers are first reviewed by the product owner and technical lead and compared to existing product releases. Gaps in features are identified. If they are generic features, they become potentially part of the product features in the roadmap. The roadmap is the input for Product development. + +To ensure clearly defined issues for project realisation, refinement sessions are organised based on the review of the roadmap backlog and customer project requirements by the product owner. Refinement sessions first clarify user requirements with project technical leads and UX manager. Secondly, the final functional and technical requirements are defined with architects. + +Sprint planning is done on a two weekly basis with the whole team and includes the combined planning of both product and project issues. Team development capacity is reserved one day before by product owner and project managers . + +## **13.4 Finance** {#13.4-finance} + +Financial management consists of financial management of projects as well as organisational financial control. + +Project financial management reviews whether projects are planned with a clear coverage of costs with margin for product development and other costs, taking into account a risk margin. Throughout the project, time spent and costs are monitored. + +Financial control includes management of organisational expenses, taxes, salaries and invoicing. The objective is to manage OPEX, cashflow and balance sheet. Yearly reporting and tax statements are organised and registered. diff --git a/docs/data-protection-and-privacy-management.md b/docs/data-protection-and-privacy-management.md new file mode 100644 index 0000000..a35bb68 --- /dev/null +++ b/docs/data-protection-and-privacy-management.md @@ -0,0 +1,23 @@ +--- +sidebar_position: 11 +--- + +# 11. Data Protection and Privacy Management + +## **11.1 Data Classification** {#11.1-data-classification} + +Information handled by OpenRemote is classified according to its sensitivity and importance to the organisation. Classification in three categories helps determine appropriate protection measures for each type of information: internal documentation, customer data, and publicly available information. + +Internal documentation and customer data are assigned an owner and shared on a need to know basis with the team as indicated in [Tools, Systems and Evidence Repositories](./evidence-register-tools-and-systems). Publicly available information is listed in the same overview. + +## **11.2 Retention Policy** {#11.2-retention-policy} + +OpenRemote retains operational and organisational records for an unlimited period unless legal, operational, or contractual requirements require a limited retention period. + +When required, data is securely deleted or archived. + +## **11.3 Data Subject Rights Handling – PLACEHOLDER** {#11.3-data-subject-rights-handling-–-placeholder} + +When personal data is processed, OpenRemote supports the rights of individuals as defined by GDPR, including requests for access, correction, or deletion of personal data. + +Requests are handled through defined procedures and documented accordingly. diff --git a/docs/evidence-register-tools-and-systems.md b/docs/evidence-register-tools-and-systems.md new file mode 100644 index 0000000..1a92ca8 --- /dev/null +++ b/docs/evidence-register-tools-and-systems.md @@ -0,0 +1,90 @@ +--- +sidebar_position: 16 +--- + +# 16. Evidence register Tools and Systems + +## **16.1 Information assets, repositories and Software Tools** {#16.1-information-assets,-repositories-and-software-tools} + +All information assets, repositories and software tools are organised as Cloud services with default back-up and restore mechanisms, version control, enabling location and device independent work environment. + +The management team has administrative access to all tools, via Bitwarden. Team members have access to the different tools based on roles, managed by the respective process owners. The following tools are used. + +| Software tool | Access beyond mgt | Service provider | +| :---- | :---- | :---- | +| **Communication** | | | +| Website domain [openremote.org](http://openremote.org) | \- | DNS, redirect | +| Website domain [openremote.com](http://openremote.com) | \- | DNS, redirect | +| Website domain [openremote.io](https://openremote.io/) and countries | UX and Motion designer, Maintainer | DNS, AWS Lightsail | +| E-mail server | \- | Google Workspace | +| E-mail marketing | \- | Mailchimp | +| Video Channel OpenRemotePro | \- | YouTube | +| Internal communication channels | All (write) | Slack | +| Forum | All (write) | Discourse | +| X | \- | | +| Linkedin Company page | CEO | | +| Facebook | \- | | +| | | | +| **Development environment & Services** | | | +| Code repository and planning | All (write) | GitHub | +| Apple Appstore account | Developers | | +| Google Play account | Developers | | +| Project server hosting | Developers project (manage) | AWS, Hetzner, a.o. | +| Build artefacts | Developers | Docker Hub, Maven Central, NPM | +| Health Monitoring Service | Developers | AWS CloudWatch | +| | | | +| **Sales & Project management** | | | +| CRM | Sales, Product owner | Zoho CRM | +| Project planning | All (per project) | GitHub | +| Documentation network drive | Project team | Google Workspace | +| | | | +| **Financial** | | | +| Accountancy | Financial Controller | Snelstart | +| Payroll system | Financial Controller | Visma | +| Bank account | Financial Controller | | + +## **16.2 Reporting and Documentation** {#16.2-reporting-and-documentation} + +To support the processes several documents are available to document the activities within these processes, monitor their performance, define and track improvements, and communicate to relevant stakeholders. Below is the list of available documentation, the owner, access rights, and its location. Documents are stored and back-ed up and archived indefinitely. + +| Report or document | Owner | Access beyond management | Location | +| :---- | :---- | :---- | :---- | +| Weekly meeting summary | CEO/CTO | All | Network drive | +| Half yearly meeting summary | CEO | All | Network Drive | +| Project communication | Project manager | Project team | Network Drive, Slack | +| Project timesheets | Project manager | Project team | Network drive | +| Strategy document | Management team | All | Network Drive | +| Customer leads and contacts | CEO | Sales | CRM system | +| Pipeline time and effort | CEO | All | Network Drive | +| Project proposals | Project manager | All | Network Drive | +| Purchase orders | CEO | Project manager | Network Drive | +| Commercial license agreements | CEO | Project manager | Network Drive | +| Development code | CTO | All | GitHub | +| Documentation | CTO | All | GitHub repo | +| Roadmap and product requirements | Product owner | All | Network Drive | +| Sprint planning | Product owner | All | GitHub | +| Health status reports | CTO | All | CloudWatch | +| Community communication | CEO, CTO | All | Discourse | +| Contributor license agreements | CTO | | Network Drive | +| Stock agreements | CEO | Only Chairman Board | Network Drive | +| Consultancy agreements | CEO | Only Chairman Board | Network Drive | +| Employee contracts | CEO | Only Chairman Board | Network Drive | +| Work regulations | CEO | All | Network Drive | +| Risk management register | CEO | All | Network Drive | +| Quality KPIs and improvement | CEO | All | Network Drive | +| Data security and improvement | CEO | All | Network Drive | +| Business Continuity | CEO | All | Network Drive | +| Disaster Recovery | CEO | All | Network Drive | +| Project pricing and costs sheet | CEO | Project managers | Network Drive | +| Financial project monitoring | CEO | Only Chairman Board | Network Drive | +| OPEX monitoring | CEO | Only Chairman Board | Network Drive | +| Tax reporting | Financial Controller[^1] | | | +| Quality handbook (including references) | CEO | All | Online handbook | + +## **16.3 Access Control to Tools** {#16.3-access-control-to-tools} + +Access to organisational tools and platforms is managed according to user roles and responsibilities. Administrative access is restricted to authorised personnel and protected through secure authentication mechanisms. + +Access permissions are reviewed periodically to ensure they remain appropriate. + +[^1]: Role is outsourced diff --git a/docs/incident-management-and-nis2-compliance.md b/docs/incident-management-and-nis2-compliance.md new file mode 100644 index 0000000..3274242 --- /dev/null +++ b/docs/incident-management-and-nis2-compliance.md @@ -0,0 +1,23 @@ +--- +sidebar_position: 8 +--- + +# 8. Incident Management and NIS2 Compliance + +## **8.1 Incident Response Plan – PLACEHOLDER** {#8.1-incident-response-plan-–-placeholder} + +OpenRemote maintains procedures for responding to operational or security incidents affecting its systems or services. The incident response process includes identification, containment, resolution, and documentation of incidents. + +Roles and communication channels are defined to ensure that incidents are handled efficiently. + +## **8.2 NIS2 Reporting Obligations – PLACEHOLDER** {#8.2-nis2-reporting-obligations-–-placeholder} + +When incidents affecting essential services occur, OpenRemote follows applicable reporting obligations under the NIS2 Directive. Relevant authorities may be informed according to the required timelines. + +Incident documentation supports regulatory reporting and internal review. + +## **8.3 Post-Incident Review – PLACEHOLDER** {#8.3-post-incident-review-–-placeholder} + +After resolving an incident, OpenRemote conducts a review to identify the root cause and determine whether improvements are required in processes or controls. + +Lessons learned are documented and integrated into improvement activities. diff --git a/docs/information-security-management-system.md b/docs/information-security-management-system.md new file mode 100644 index 0000000..35d983e --- /dev/null +++ b/docs/information-security-management-system.md @@ -0,0 +1,28 @@ +--- +sidebar_position: 3 +--- +# 3. Information Security Management System (ISMS) + +## **3.1 ISMS Scope Definition** {#3.1-isms-scope-definition} + +The Information Security Management System (ISMS) covers the organisational processes, technical infrastructure, and information assets required for the development, operation, and delivery of OpenRemote software and services. The scope includes product development, project realisation, hosting and maintenance services, internal operational tools, and associated data processing activities. + +The ISMS applies to all employees, contractors, and contributors involved in the operation of OpenRemote services and development activities. The scope also includes cloud infrastructure, code repositories, development environments, and collaboration platforms used to support these activities. + +## **3.2 Document Control and Record Management** {#3.2-document-control-and-record-management} + +OpenRemote maintains controlled documentation to ensure that policies, procedures, and operational records remain accurate, traceable, and up to date. Documents related to the quality and security management system are version controlled and publicly published or stored in secure repositories when access should be restricted to authorised personnel ([see section 16](./evidence-register-tools-and-systems)). + +Changes to policies and procedures are reviewed and approved by the relevant process owners before publication. Historical versions are archived to maintain traceability and support audit requirements. Records generated during operational activities, such as meeting reports, incident reports, and audit results, are retained according to defined retention policies. + +## **3.3 Evidence Register** {#3.3-evidence-register} + +The evidence register for tools and services provides a structured overview of documentation and system records that demonstrate the implementation of organisational processes and security controls ([see section 16](https://docs.google.com/document/d/1h8XZPTz7iXRbi2q1xlxtmhlsGH6GRX0C/edit?pli=1#heading=h.yki34t5ju6ez)). Evidence may include monitoring logs, development records, meeting minutes, incident reports, and system configuration documentation. + +The register links each key control or process to the relevant source of evidence and identifies the responsible owner for maintaining that information . This approach ensures transparency and facilitates internal reviews and external audits. + +## **3.4 Control Mapping (ISO27001 – NIS2 – CRA)** {#3.4-control-mapping-(iso27001-–-nis2-–-cra)} + +OpenRemote maintains a mapping between its internal processes and the security requirements defined in ISO27001, the NIS2 Directive, and the Cyber Resilience Act. This mapping ensures that implemented controls can be traced to the relevant regulatory requirements ([see Annex A](./annexes/annex-a-statement-of-applicability)). + +The mapping allows the organisation to demonstrate compliance and identify areas where additional controls may be required. The detailed control mapping is maintained in the annex of this handbook and is periodically reviewed as regulations or standards evolve. diff --git a/docs/introduction.md b/docs/introduction.md index 4a9105c..96924cb 100644 --- a/docs/introduction.md +++ b/docs/introduction.md @@ -2,4 +2,24 @@ sidebar_position: 1 --- -# Introduction +# 1. Introduction + +## **1.1 Mission and Vision** {#1.1-mission-and-vision} + +OpenRemote’s mission is to enhance the services which equipment manufacturers and system integrators offer their customer base, using the opportunities which the Internet of Things provides them. + +We do this by offering a concise and complete open source software IoT platform and all services required for designing, realising, hosting and supporting the product. + +Our vision is an open source approach as the best way to serve customers in a new and emerging market. Open source offers the highest level of warranty for users to be future proof and independent. Open source is reflected not just in the license terms of our software but also in the transparency and willingness to share our knowledge and way of working to our customers, helping them to succeed. We believe that professional services, in addition to an open source approach, are a key success factor in helping businesses to adopt IoT. + +The company OpenRemote is created, to manage the open source project as well as organise the professional services around the OpenRemote open source project. The company follows a professional Open Source methodology with all legal, financial, security and contractual agreements in place. It also means that top contributors usually end up participating in the company, first as contributors, then as consultants or business developers, then as full time employees or even co-owners. + +## **1.2 Scope and applicability of the quality handbook** {#1.2-scope-and-applicability-of-the-quality-handbook} + +The scope of this quality handbook covers product development, project realisation, hosting and maintenance, professional services, and internal operations. + +OpenRemote operates in a regulatory environment where cybersecurity, data protection, and operational resilience are essential. The organisation aligns its internal processes with recognised standards and European regulatory frameworks including ISO/IEC 27001 for information security management, the NIS2 Directive for cybersecurity risk management and incident reporting, the Cyber Resilience Act (CRA) for secure software development and vulnerability management, and the General Data Protection Regulation (GDPR) for personal data protection. + +This quality handbook describes the processes and controls implemented to address these requirements. The handbook ensures that security, resilience, and privacy considerations are integrated into the design, development, deployment, and operation of OpenRemote software and services. + +The handbook applies to all employees and contractors, involved in the operation of OpenRemote services and development activities. The scope also includes cloud infrastructure, code repositories, development environments, and collaboration platforms used to support these activities. \ No newline at end of file diff --git a/docs/operational-security-and-infrastructure-protection.md b/docs/operational-security-and-infrastructure-protection.md new file mode 100644 index 0000000..718b86e --- /dev/null +++ b/docs/operational-security-and-infrastructure-protection.md @@ -0,0 +1,35 @@ +--- +sidebar_position: 7 +--- + +# 7. Operational Security and Infrastructure Protection + +## **7.1 Hosting and Maintenance** {#7.1-hosting-and-maintenance} + +In case OpenRemote is requested to host the Software as a service, the sales manager agrees on a service and maintenance contract which covers both hosting as well as maintenance activities. + +When hosting the production environment, the environment is actively monitored and a communication channel is agreed with the customer for support. The development environments, including a test or staging environment remain available, in case maintenance activities are required. + +Service requests (bugs and issues) are reviewed by the sales and account manager, judging coverage and severity level. Together with support manager he plans follow up as part of project realisation. Preventive maintenance, based on new software releases of OpenRemote or 3rd party software, are planned in conjunction with product development, if part of the service agreement. + +## **7.2 Data Security and Privacy** {#7.2-data-security-and-privacy} + +We maintain a living document around data security and privacy, intended to regularly perform an internal audit or one with customers to validate our performance regarding data security and privacy. See [Data Security](https://docs.google.com/spreadsheets/d/1ZQamPOVlZD5hcV3vi7DTev9K7-b2bxa8?rtpof=true&usp=drive_fs) + +## **7.3 Identity and Access Management** {#7.3-identity-and-access-management} + +Access to organisational systems and services is granted based on defined roles and responsibilities. Access rights are limited to the permissions required to perform assigned tasks. + +Access is reviewed periodically, as part of data security and privacy, to ensure that permissions remain appropriate and that accounts belonging to former employees or contributors are removed. + +## **7.4 Logging and Monitoring** {#7.4-logging-and-monitoring} + +Operational systems and infrastructure components generate logs that provide visibility into system activity. Monitoring tools are used to detect anomalies, performance issues, or potential security incidents. + +Logs are retained for a defined period and reviewed when necessary to support operational monitoring or incident investigations. + +## **7.5 Change Management** {#7.5-change-management} + +Changes to infrastructure, software, or operational processes are tested when appropriate to minimise disruption to services. + +Records of significant changes are maintained to support traceability and operational review, by saving GitHub history, and releases of code, documentation and handbook. diff --git a/docs/organisational-context-governance.md b/docs/organisational-context-governance.md new file mode 100644 index 0000000..d26bed4 --- /dev/null +++ b/docs/organisational-context-governance.md @@ -0,0 +1,37 @@ +--- +sidebar_position: 2 +--- + +# 2. Organisational Context and Governance + +## **2.1 Legal Entity and Structure** {#2.1-legal-entity-and-structure} + +OpenRemote is an open source project with a professional organisation registered in The Netherlands (as of here called OpenRemote). The management team consists of the CEO, CTO, and Product owner. + +## **2.2 Management Commitment** {#2.2-management-commitment} + +The management team of OpenRemote, consists of CEO, CTO, and Product owner. The Chairman of the Advisory Board advises on long term ambition and performance and improvement targets. + +The management team is committed to quality, safeguarded by peer review and a PDCA cycle which is linked to a short term (daily and weekly) and long term (half-yearly) cycle. + +The half year cycle is organised as a face to face meeting of the whole organisation, during which strategic direction, product development (roadmap), key project realisations, and overall planning are evaluated. Performance related to quality of processes is reviewed and used to define improvements, translated into actions. A risk assessment approach is used to set priorities and select improvement actions. + +The daily (stand-up) and (two)weekly meeting cycle, with the complete team, is primarily intended to review and plan the running program of projects as well as product development and define and monitor short term corrective or preventive quality improvement actions. The meeting also monitors the long term improvement actions defined during the half year cycle. + +## **2.3 Roles and Responsibilities – EXPANDED PLACEHOLDER** {#2.3-roles-and-responsibilities-–-expanded-placeholder} + +OpenRemote defines clear roles and responsibilities to ensure effective governance of quality, security, and operational processes. The CEO is accountable for the overall management system, including quality and compliance. The CTO is responsible for technical governance, product security, and Product owner for a secure development lifecycle. + +Specific responsibilities are assigned for information security management, incident response, risk management, and system operations. Segregation of duties is applied where appropriate to reduce risks related to unauthorised access or conflicting responsibilities, particularly in areas such as system administration, code deployment, and financial management. + +| Role | Roles and Responsibilities | +| :---- |:---------------------------------------------------------------------------------------------------------------------| +| CEO | Sales
Financial and Personnel management
Quality officer | +| CTO | System architecture
Technical Roadmap
Security lead and incidence response coordinator
Infrastructure administration | +| Quality officer | Security officer, ISMS owner,
Quality compliance monitoring | +| Product owner | Functional Roadmap and programming
Capacity and sprint planning
Secure development lifecycle | +| Project manager | Project realisation
Project production deployment | +| EPIC owner | Product EPIC management | +| Project technical lead | Project architecture
Technical project realisation | +| UX manager | Marketing visual communication
User requirements refinement for product features
Product UX | +| Software developers | Code development
Code review of development work of colleagues | diff --git a/docs/people-resource-management.md b/docs/people-resource-management.md new file mode 100644 index 0000000..ab3c930 --- /dev/null +++ b/docs/people-resource-management.md @@ -0,0 +1,27 @@ +--- +sidebar_position: 12 +--- + +# 12. People Resource Management + +## **12.1 People Resource Management** {#12.1-people-resource-management} + +As OpenRemote is an open source company, people resource management starts at user management, the people who actively get involved as users of OpenRemote source code. We facilitate a forum for this group of users, which is moderated by the core OpenRemote team as a shared responsibility. In this phase, OpenRemote actively looks out for Contributor candidates, primarily by reviewing code contributions they make to our codebase in their own branch or projects they share in which they used the OpenRemote software. + +Users with code commits which have a high quality level are considered Contributor candidates. We request these candidates to sign a Contributor License Agreement before merging their code with our main branch, except for limited contributions (e.g. a typo fix or single line change). In return, as part of managing the contributor group, we can offer major contributors a compensation for their work. + +OpenRemote core roles for delivering its professional services are filled in by employees on employee contracts or with a consultancy agreement. The consultancy agreement covers similar agreements as within employee contracts and are organised, negotiated and signed between OpenRemote and staff. Additional work regulations are in place as addition to individual contracts. + +Performance of staff is reviewed on a two weekly basis by management, combined with adjustments to roles, or offering additional learning opportunities for further improvement. CEO and Chairman of the board decide on yearly appraisals and related salaries. + +## **12.2 Security Awareness Training** {#12.2-security-awareness-training} + +Employees and contributors are informed about security risks and responsible behaviour when working with organisational systems. This is part of the company Work regulations ([see section 16](./evidence-register-tools-and-systems)). + +Training and awareness activities help ensure that security responsibilities are understood across the organisation. + +## **12.3 Offboarding Controls** {#12.3-offboarding-controls} + +When employees or contributors leave the organisation, their access to systems and services is removed in a timely manner. + +Relevant responsibilities and information are transferred to appropriate personnel to ensure operational continuity. diff --git a/docs/performance-evaluation-and-retrospective.md b/docs/performance-evaluation-and-retrospective.md new file mode 100644 index 0000000..8ed7868 --- /dev/null +++ b/docs/performance-evaluation-and-retrospective.md @@ -0,0 +1,25 @@ +--- +sidebar_position: 14 +--- + +# 14. Performance Evaluation and retrospective + +## **14.1 KPIs** {#14.1-kpis} + +OpenRemote has defined a series of KPIs to monitor the overall performance of the organisation. Targets for the KPIs, as well as measurement and evaluations (internal audit) are done on a half yearly basis, as part of the half yearly team meetings and management reviews. + +If relevant, improvement plans derived from the reviews are additionally monitored as part of the weekly meetings. In case of urgent corrective actions, they can also become part of project activities and their respective project reviews. + +The Key Performance Indicators are part of a yearly [quality report](https://docs.google.com/presentation/d/1SQ44S_9UqY3gidl3je3oWDCApJw5vg9U?rtpof=true&usp=drive_fs) and include KPIs for Customer focus, Financials, People, Quality of processes and non conformity and Quality improvement. + +## **14.2 Internal Retrospective** {#14.2-internal-retrospective} + +OpenRemote monthly reviews its processes and controls through internal retrospectives. These retrospectives look back and evaluate interaction, processes and tools, what went well and whether improvements are required. + +Findings are documented and tracked until resolved as part of regular issues or the quality report. + +## **14.3 Management Review** {#14.3-management-review} + +The management team reviews the strategy and effectiveness of the quality and security management system on a two weekly basis. The review considers strategy, key processes, performance indicators, risk status, incident reports, and improvement actions. + +Half yearly, the outcomes of management reviews guide strategic improvements to organisational processes reflected in this quality handbook. diff --git a/docs/risk-management-framework.md b/docs/risk-management-framework.md new file mode 100644 index 0000000..f2a120e --- /dev/null +++ b/docs/risk-management-framework.md @@ -0,0 +1,34 @@ +--- +sidebar_position: 4 +--- +# 4. Risk Management Framework + +## **4.1 Risk Management Policy** {#4.1-risk-management-policy} + +OpenRemote applies a structured risk management approach to identify, analyse, and mitigate risks that may affect the organisation’s operations, information assets, or service delivery. Risk management is integrated into organisational planning, product development, and operational decision-making. + +Risks are assessed based on their likelihood and potential impact on confidentiality, integrity, availability, and business continuity. Identified risks are documented and prioritised, and mitigation actions are defined and tracked until completion in a risk management register ([see section 16](./evidence-register-tools-and-systems)). + +## **4.2 Asset Inventory** {#4.2-asset-inventory} + +OpenRemote maintains an inventory of information assets that support its services and operations. Assets include infrastructure components, software systems, repositories, cloud services, and organisational information resources. + +Each asset is assigned an owner responsible for maintaining its security and operational status. The inventory helps ensure that security controls, monitoring, and risk management activities are applied consistently across all critical systems. + +## **4.3 Risk Assessment Methodology** {#4.3-risk-assessment-methodology} + +The organisation applies a consistent methodology to evaluate risks affecting its systems and services. Risks are identified through periodic reviews of operational processes, infrastructure components, and external threat intelligence. + +For each risk, the likelihood of occurrence and potential impact are assessed. The resulting risk score determines the priority for mitigation. Risk assessments are reviewed periodically and whenever significant system or organisational changes occur. + +## **4.4 Risk Treatment Plan** {#4.4-risk-treatment-plan} + +For each identified risk, an appropriate treatment strategy is defined. Possible strategies include mitigating the risk through security controls, transferring the risk through contractual arrangements, accepting the risk when it falls within acceptable levels, or avoiding the risk entirely. + +Risk treatment actions are documented in the risk register and assigned to responsible owners. Progress on mitigation activities is monitored and reviewed during management meetings. + +## **4.5 Statement of Applicability** {#4.5-statement-of-applicability} + +The Statement of Applicability (SoA) identifies which security controls from ISO27001 ([Annex A](./annexes/annex-a-statement-of-applicability)) are applicable to OpenRemote and describes how these controls are implemented. Controls that are not applicable are documented together with their justification. + +The SoA provides a reference linking implemented controls to the organisational processes described in this handbook and serves as an important reference during internal and external audits. diff --git a/docs/secure-product-development-lifecycle.md b/docs/secure-product-development-lifecycle.md new file mode 100644 index 0000000..9dc5ec4 --- /dev/null +++ b/docs/secure-product-development-lifecycle.md @@ -0,0 +1,44 @@ +--- +sidebar_position: 5 +--- +# 5. Secure Product Development Lifecycle (Secure SDLC) + +## **5.1 Product Development Process** {#5.1-product-development-process} + +Our Software Development Lifecycle (SDLC) primarily focuses on the development of our software product, hence the reason to call it Product Development Lifecycle. For product development projects the Product owner is managing a roadmap, while function managers are responsible for feature realisation and testing & release. + +During development developers work on a separate feature branch on new product features, including tests. New code is released to the main branch after reviews, running and passing all automated tests. A CI/CD system manages the automated tests. + +In testing and review, code is tested and reviewed on a staging test environment by a colleague developer. Issues are tracked and solved, using the scrum system. Once everything is resolved, code is merged with the main branch. For an official release, once Product owner and CTO agree, an update of all packages including documentation is created, managed by a team member. + +The product feature realisation is managed the same as development for projects, described in [section 13.2](./core-operational-processes#13.2-project-realisation) as part of project realisation. + +## **5.2 Secure-by-Design Principles** {#5.2-secure-by-design-principles} + +OpenRemote integrates security considerations into the design of its software architecture and services. Security is addressed from the earliest stages of system design to reduce vulnerabilities and ensure resilient system behaviour. + +Design principles include minimising attack surfaces, applying the principle of least privilege, ensuring secure configuration by default, and implementing robust authentication and authorisation mechanisms. + +## **5.3 Secure Coding Standards** {#5.3-secure-coding-standards} + +Developers follow secure coding practices to minimise vulnerabilities in the OpenRemote platform. Code contributions are reviewed by peers before integration into the main codebase, and automated tests ensure that new functionality does not compromise system stability or security. + +Where possible, automated analysis tools are used to detect potential vulnerabilities in the code. Secure coding practices are communicated within the development team and incorporated into the development workflow. + +## **5.4 CI/CD Security Controls and penetration tests** {#5.4-ci/cd-security-controls-and-penetration-tests} + +Continuous integration and deployment pipelines include safeguards to protect the integrity of the software build and release process. + +Automated testing and validation steps are included in the pipeline to verify the functionality and integrity of new releases before deployment. Penetration tests are performed yearly. + +## **5.5 SBOM Management – PLACEHOLDER** {#5.5-sbom-management-–-placeholder} + +To maintain transparency regarding software components, OpenRemote maintains a software bill of materials (SBOM) describing dependencies used in its software releases. The SBOM provides visibility into third-party libraries and components integrated into the platform. + +This information supports vulnerability monitoring and enables rapid identification of affected components when security issues are reported in external dependencies. + +## **5.6 End-of-Life and Support Policy** {#5.6-end-of-life-and-support-policy} + +OpenRemote defines support periods for software releases and communicates these periods to users and customers. When a version reaches its end of support, users are informed and encouraged to migrate to supported versions. + +Security updates and bug fixes are prioritised for supported releases to maintain system reliability and security. diff --git a/docs/supply-chain-and-third-party-risk-management.md b/docs/supply-chain-and-third-party-risk-management.md new file mode 100644 index 0000000..a54174c --- /dev/null +++ b/docs/supply-chain-and-third-party-risk-management.md @@ -0,0 +1,21 @@ +--- +sidebar_position: 10 +--- + +# 10. Supply Chain and Third-Party Risk Management + +## **10.1 Supplier Identification** {#10.1-supplier-identification} + +OpenRemote maintains an overview of suppliers and service providers that support its operations. These include cloud infrastructure providers, software platforms, and service partners ([see chapter 16](./evidence-register-tools-and-systems)). + +## **10.2 Third-Party Security Assessment** {#10.2-third-party-security-assessment} + +When selecting or reviewing suppliers, OpenRemote considers the security posture of the supplier and the potential risks associated with their services. + +Where relevant, contractual agreements include provisions related to security and data protection. + +## **10.3 Open Source Dependency Governance** {#10.3-open-source-dependency-governance} + +OpenRemote actively manages dependencies on third-party open source components used in its software platform (see [5.5 SBOM Management](./secure-product-development-lifecycle#5.5-sbom-management-–-placeholder)). + +Dependencies are monitored for security vulnerabilities and updated when necessary to maintain system security (see [6\. Vulnerability Management and Coordinated Disclosure](./vulnerability-management-and-coordinated-disclosure)). diff --git a/docs/vulnerability-management-and-coordinated-disclosure.md b/docs/vulnerability-management-and-coordinated-disclosure.md new file mode 100644 index 0000000..75702ab --- /dev/null +++ b/docs/vulnerability-management-and-coordinated-disclosure.md @@ -0,0 +1,29 @@ +--- +sidebar_position: 6 +--- + +# 6. Vulnerability Management and Coordinated Disclosure + +## **6.1 Vulnerability Monitoring** {#6.1-vulnerability-monitoring} + +OpenRemote continuously monitors vulnerability information sources relevant to the technologies used within its platform. These sources include security advisories, dependency vulnerability databases, and vendor notifications. + +Potential vulnerabilities, as discovered by dependency scanning during builds, are reviewed and evaluated immediately on a daily basis to determine their impact on OpenRemote systems or software components. + +## **6.2 Patch Management Policy** {#6.2-patch-management-policy} + +Security patches and updates are applied in a structured manner to address identified vulnerabilities. Critical vulnerabilities are prioritised and addressed as quickly as possible, while lower-risk issues are handled during scheduled development and maintenance cycles. + +Patch management activities are coordinated between product development and project operations teams to ensure system stability. + +## **6.3 Coordinated Vulnerability Disclosure – PLACEHOLDER** {#6.3-coordinated-vulnerability-disclosure-–-placeholder} + +OpenRemote supports responsible disclosure of security vulnerabilities by external parties. Individuals or organisations discovering vulnerabilities are encouraged to report them through designated communication channels. + +Reported vulnerabilities are assessed and addressed in a coordinated manner before public disclosure. + +## **6.4 Security Advisory Process – PLACEHOLDER** {#6.4-security-advisory-process-–-placeholder} + +When security issues affecting OpenRemote software are confirmed, a security advisory may be issued to inform users about the vulnerability and recommended mitigation actions. + +Security advisories are reviewed and approved internally before publication and are archived for reference. diff --git a/sidebars.ts b/sidebars.ts index 8951cba..cef433d 100644 --- a/sidebars.ts +++ b/sidebars.ts @@ -13,6 +13,33 @@ import type {SidebarsConfig} from '@docusaurus/plugin-content-docs'; const sidebars: SidebarsConfig = { docsSidebar: [ 'introduction', + 'organisational-context-governance', + 'information-security-management-system', + 'risk-management-framework', + 'secure-product-development-lifecycle', + 'vulnerability-management-and-coordinated-disclosure', + 'operational-security-and-infrastructure-protection', + 'incident-management-and-nis2-compliance', + 'business-continuity-and-operational-resilience', + 'supply-chain-and-third-party-risk-management', + 'data-protection-and-privacy-management', + 'people-resource-management', + 'core-operational-processes', + 'performance-evaluation-and-retrospective', + 'continuous-improvement', + 'evidence-register-tools-and-systems', + { + type: 'category', + label: 'Annexes', + link: { + type: 'doc', + id: 'annexes/index', + }, + items: [ + 'annexes/annex-a-statement-of-applicability', + 'annexes/annex-b-incident-response-templates', + ], + }, ], }; From 1cd5de1246c0885c820aad0580a4991011b94886 Mon Sep 17 00:00:00 2001 From: Eric Bariaux <375613+ebariaux@users.noreply.github.com> Date: Tue, 5 May 2026 15:29:18 +0200 Subject: [PATCH 2/6] Fix link --- docs/information-security-management-system.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/information-security-management-system.md b/docs/information-security-management-system.md index 35d983e..9b81f9a 100644 --- a/docs/information-security-management-system.md +++ b/docs/information-security-management-system.md @@ -17,7 +17,7 @@ Changes to policies and procedures are reviewed and approved by the relevant pro ## **3.3 Evidence Register** {#3.3-evidence-register} -The evidence register for tools and services provides a structured overview of documentation and system records that demonstrate the implementation of organisational processes and security controls ([see section 16](https://docs.google.com/document/d/1h8XZPTz7iXRbi2q1xlxtmhlsGH6GRX0C/edit?pli=1#heading=h.yki34t5ju6ez)). Evidence may include monitoring logs, development records, meeting minutes, incident reports, and system configuration documentation. +The evidence register for tools and services provides a structured overview of documentation and system records that demonstrate the implementation of organisational processes and security controls ([see section 16](./evidence-register-tools-and-systems)). Evidence may include monitoring logs, development records, meeting minutes, incident reports, and system configuration documentation. The register links each key control or process to the relevant source of evidence and identifies the responsible owner for maintaining that information . This approach ensures transparency and facilitates internal reviews and external audits. From 9ce7e10c99dade4bfa0080ce652f0dd5cd6a76f3 Mon Sep 17 00:00:00 2001 From: Eric Bariaux <375613+ebariaux@users.noreply.github.com> Date: Tue, 5 May 2026 15:29:18 +0200 Subject: [PATCH 3/6] Rewording --- docs/evidence-register-tools-and-systems.md | 2 +- docs/secure-product-development-lifecycle.md | 8 ++++++-- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/docs/evidence-register-tools-and-systems.md b/docs/evidence-register-tools-and-systems.md index 1a92ca8..eb989fd 100644 --- a/docs/evidence-register-tools-and-systems.md +++ b/docs/evidence-register-tools-and-systems.md @@ -45,7 +45,7 @@ The management team has administrative access to all tools, via Bitwarden. Team ## **16.2 Reporting and Documentation** {#16.2-reporting-and-documentation} -To support the processes several documents are available to document the activities within these processes, monitor their performance, define and track improvements, and communicate to relevant stakeholders. Below is the list of available documentation, the owner, access rights, and its location. Documents are stored and back-ed up and archived indefinitely. +To support the processes several documents are available to document the activities within these processes, monitor their performance, define and track improvements, and communicate to relevant stakeholders. Below is the list of available documentation, the owner, access rights, and its location. Documents are stored and backed up and archived indefinitely. | Report or document | Owner | Access beyond management | Location | | :---- | :---- | :---- | :---- | diff --git a/docs/secure-product-development-lifecycle.md b/docs/secure-product-development-lifecycle.md index 9dc5ec4..bc1f21f 100644 --- a/docs/secure-product-development-lifecycle.md +++ b/docs/secure-product-development-lifecycle.md @@ -7,9 +7,13 @@ sidebar_position: 5 Our Software Development Lifecycle (SDLC) primarily focuses on the development of our software product, hence the reason to call it Product Development Lifecycle. For product development projects the Product owner is managing a roadmap, while function managers are responsible for feature realisation and testing & release. -During development developers work on a separate feature branch on new product features, including tests. New code is released to the main branch after reviews, running and passing all automated tests. A CI/CD system manages the automated tests. +During development developers work on a separate feature branch on new product features, including tests. +New code is released to the main branch after reviews, running and passing all automated tests. A CI/CD system manages the automated tests. -In testing and review, code is tested and reviewed on a staging test environment by a colleague developer. Issues are tracked and solved, using the scrum system. Once everything is resolved, code is merged with the main branch. For an official release, once Product owner and CTO agree, an update of all packages including documentation is created, managed by a team member. +In testing and review, code is tested and reviewed on a staging test environment by a colleague developer. +Issues are tracked and solved, using the scrum framework. +Once everything is resolved, code is merged with the main branch. +For an official release, once Product owner and CTO agree, an update of all packages including documentation is created, managed by a team member. The product feature realisation is managed the same as development for projects, described in [section 13.2](./core-operational-processes#13.2-project-realisation) as part of project realisation. From 6f93bd793000c2d6783fd6176a95cca155f74ff0 Mon Sep 17 00:00:00 2001 From: Eric Bariaux <375613+ebariaux@users.noreply.github.com> Date: Tue, 5 May 2026 15:29:18 +0200 Subject: [PATCH 4/6] Make reference a link --- docs/core-operational-processes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/core-operational-processes.md b/docs/core-operational-processes.md index d7bbc3d..24ecd6c 100644 --- a/docs/core-operational-processes.md +++ b/docs/core-operational-processes.md @@ -18,7 +18,7 @@ Customers who distribute the code commercially can agree on a commercial license ## **13.2 Project Realisation** {#13.2-project-realisation} -For project realisation, an agile approach is used with iterations based on issues as defined as part of roadmap, refinement and sprint planning (section 13.3) supported by a scrum based planning system. As part of realisation, automated system and unit tests are developed and included to safeguard code quality. +For project realisation, an agile approach is used with iterations based on issues as defined as part of roadmap, refinement and sprint planning ([section 13.3](./core-operational-processes#13.3-roadmapping,-refinement-and-sprint-planning)) supported by a scrum based planning system. As part of realisation, automated system and unit tests are developed and included to safeguard code quality. Daily standups are organised in two rounds with the complete team, the first for each participant to share what he has worked on, will work on and raise impediments. The second round is to discuss impediments and possible resolutions. From ac94d78d2898f4524863d674bb59a5e569373a8f Mon Sep 17 00:00:00 2001 From: Eric Bariaux <375613+ebariaux@users.noreply.github.com> Date: Tue, 5 May 2026 16:51:43 +0200 Subject: [PATCH 5/6] Add user friendly note for placeholders --- ...ss-continuity-and-operational-resilience.md | 6 +++++- docs/data-protection-and-privacy-management.md | 6 +++++- .../incident-management-and-nis2-compliance.md | 18 +++++++++++++++--- docs/organisational-context-governance.md | 6 +++++- docs/secure-product-development-lifecycle.md | 6 +++++- ...ty-management-and-coordinated-disclosure.md | 12 ++++++++++-- 6 files changed, 45 insertions(+), 9 deletions(-) diff --git a/docs/business-continuity-and-operational-resilience.md b/docs/business-continuity-and-operational-resilience.md index 996904f..de15030 100644 --- a/docs/business-continuity-and-operational-resilience.md +++ b/docs/business-continuity-and-operational-resilience.md @@ -45,7 +45,11 @@ Our main services are The details and status of the disaster recovery plan is laid down in situation assessment which is continuously improved and described in [disaster recovery](https://docs.google.com/document/d/1zSvdKXf0o0t_39qCwqVoqNm4YByEAkhBjUL57YM8KMs/edit?usp=sharing). -## **9.3 Resilience Testing – PLACEHOLDER** {#9.3-resilience-testing-–-placeholder} +## **9.3 Resilience Testing** {#9.3-resilience-testing-–-placeholder} + +:::note +This is work in progress and not fully implemented yet, as OpenRemote, we are working on this subject and will publish an update soon. +::: OpenRemote periodically tests the resilience of its systems and recovery procedures. Tests may include backup restoration, service failover simulations, or recovery exercises. diff --git a/docs/data-protection-and-privacy-management.md b/docs/data-protection-and-privacy-management.md index a35bb68..14f4639 100644 --- a/docs/data-protection-and-privacy-management.md +++ b/docs/data-protection-and-privacy-management.md @@ -16,7 +16,11 @@ OpenRemote retains operational and organisational records for an unlimited perio When required, data is securely deleted or archived. -## **11.3 Data Subject Rights Handling – PLACEHOLDER** {#11.3-data-subject-rights-handling-–-placeholder} +## **11.3 Data Subject Rights Handling** {#11.3-data-subject-rights-handling-–-placeholder} + +:::note +This is work in progress and not fully implemented yet, as OpenRemote, we are working on this subject and will publish an update soon. +::: When personal data is processed, OpenRemote supports the rights of individuals as defined by GDPR, including requests for access, correction, or deletion of personal data. diff --git a/docs/incident-management-and-nis2-compliance.md b/docs/incident-management-and-nis2-compliance.md index 3274242..6994ac4 100644 --- a/docs/incident-management-and-nis2-compliance.md +++ b/docs/incident-management-and-nis2-compliance.md @@ -4,19 +4,31 @@ sidebar_position: 8 # 8. Incident Management and NIS2 Compliance -## **8.1 Incident Response Plan – PLACEHOLDER** {#8.1-incident-response-plan-–-placeholder} +## **8.1 Incident Response Plan** {#8.1-incident-response-plan-–-placeholder} + +:::note +This is work in progress and not fully implemented yet, as OpenRemote, we are working on this subject and will publish an update soon. +::: OpenRemote maintains procedures for responding to operational or security incidents affecting its systems or services. The incident response process includes identification, containment, resolution, and documentation of incidents. Roles and communication channels are defined to ensure that incidents are handled efficiently. -## **8.2 NIS2 Reporting Obligations – PLACEHOLDER** {#8.2-nis2-reporting-obligations-–-placeholder} +## **8.2 NIS2 Reporting Obligations** {#8.2-nis2-reporting-obligations-–-placeholder} + +:::note +This is work in progress and not fully implemented yet, as OpenRemote, we are working on this subject and will publish an update soon. +::: When incidents affecting essential services occur, OpenRemote follows applicable reporting obligations under the NIS2 Directive. Relevant authorities may be informed according to the required timelines. Incident documentation supports regulatory reporting and internal review. -## **8.3 Post-Incident Review – PLACEHOLDER** {#8.3-post-incident-review-–-placeholder} +## **8.3 Post-Incident Review** {#8.3-post-incident-review-–-placeholder} + +:::note +This is work in progress and not fully implemented yet, as OpenRemote, we are working on this subject and will publish an update soon. +::: After resolving an incident, OpenRemote conducts a review to identify the root cause and determine whether improvements are required in processes or controls. diff --git a/docs/organisational-context-governance.md b/docs/organisational-context-governance.md index d26bed4..ef24293 100644 --- a/docs/organisational-context-governance.md +++ b/docs/organisational-context-governance.md @@ -18,7 +18,11 @@ The half year cycle is organised as a face to face meeting of the whole organisa The daily (stand-up) and (two)weekly meeting cycle, with the complete team, is primarily intended to review and plan the running program of projects as well as product development and define and monitor short term corrective or preventive quality improvement actions. The meeting also monitors the long term improvement actions defined during the half year cycle. -## **2.3 Roles and Responsibilities – EXPANDED PLACEHOLDER** {#2.3-roles-and-responsibilities-–-expanded-placeholder} +## **2.3 Roles and Responsibilities** {#2.3-roles-and-responsibilities-–-expanded-placeholder} + +:::note +This is preliminary information, as OpenRemote, we are working on this subject and will publish an update soon. +::: OpenRemote defines clear roles and responsibilities to ensure effective governance of quality, security, and operational processes. The CEO is accountable for the overall management system, including quality and compliance. The CTO is responsible for technical governance, product security, and Product owner for a secure development lifecycle. diff --git a/docs/secure-product-development-lifecycle.md b/docs/secure-product-development-lifecycle.md index bc1f21f..2a08f6c 100644 --- a/docs/secure-product-development-lifecycle.md +++ b/docs/secure-product-development-lifecycle.md @@ -35,7 +35,11 @@ Continuous integration and deployment pipelines include safeguards to protect th Automated testing and validation steps are included in the pipeline to verify the functionality and integrity of new releases before deployment. Penetration tests are performed yearly. -## **5.5 SBOM Management – PLACEHOLDER** {#5.5-sbom-management-–-placeholder} +## **5.5 SBOM Management** {#5.5-sbom-management-–-placeholder} + +:::note +This is work in progress and not fully implemented yet, as OpenRemote, we are working on this subject and will publish an update soon. +::: To maintain transparency regarding software components, OpenRemote maintains a software bill of materials (SBOM) describing dependencies used in its software releases. The SBOM provides visibility into third-party libraries and components integrated into the platform. diff --git a/docs/vulnerability-management-and-coordinated-disclosure.md b/docs/vulnerability-management-and-coordinated-disclosure.md index 75702ab..4fc3842 100644 --- a/docs/vulnerability-management-and-coordinated-disclosure.md +++ b/docs/vulnerability-management-and-coordinated-disclosure.md @@ -16,13 +16,21 @@ Security patches and updates are applied in a structured manner to address ident Patch management activities are coordinated between product development and project operations teams to ensure system stability. -## **6.3 Coordinated Vulnerability Disclosure – PLACEHOLDER** {#6.3-coordinated-vulnerability-disclosure-–-placeholder} +## **6.3 Coordinated Vulnerability Disclosure** {#6.3-coordinated-vulnerability-disclosure-–-placeholder} + +:::note +This is work in progress and not fully implemented yet, as OpenRemote, we are working on this subject and will publish an update soon. +::: OpenRemote supports responsible disclosure of security vulnerabilities by external parties. Individuals or organisations discovering vulnerabilities are encouraged to report them through designated communication channels. Reported vulnerabilities are assessed and addressed in a coordinated manner before public disclosure. -## **6.4 Security Advisory Process – PLACEHOLDER** {#6.4-security-advisory-process-–-placeholder} +## **6.4 Security Advisory Process** {#6.4-security-advisory-process-–-placeholder} + +:::note +This is work in progress and not fully implemented yet, as OpenRemote, we are working on this subject and will publish an update soon. +::: When security issues affecting OpenRemote software are confirmed, a security advisory may be issued to inform users about the vulnerability and recommended mitigation actions. From f5c54f2f947614521db2dcaa4110733469b3d4b3 Mon Sep 17 00:00:00 2001 From: Eric Bariaux <375613+ebariaux@users.noreply.github.com> Date: Tue, 5 May 2026 16:53:32 +0200 Subject: [PATCH 6/6] Add indication about restricted access to certain documents --- docs/business-continuity-and-operational-resilience.md | 2 +- docs/operational-security-and-infrastructure-protection.md | 2 +- docs/performance-evaluation-and-retrospective.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/business-continuity-and-operational-resilience.md b/docs/business-continuity-and-operational-resilience.md index de15030..511442a 100644 --- a/docs/business-continuity-and-operational-resilience.md +++ b/docs/business-continuity-and-operational-resilience.md @@ -43,7 +43,7 @@ Our main services are * Google Playstore * Apple account -The details and status of the disaster recovery plan is laid down in situation assessment which is continuously improved and described in [disaster recovery](https://docs.google.com/document/d/1zSvdKXf0o0t_39qCwqVoqNm4YByEAkhBjUL57YM8KMs/edit?usp=sharing). +The details and status of the disaster recovery plan is laid down in situation assessment which is continuously improved and described in [disaster recovery](https://docs.google.com/document/d/1zSvdKXf0o0t_39qCwqVoqNm4YByEAkhBjUL57YM8KMs/edit?usp=sharing) (restricted access). ## **9.3 Resilience Testing** {#9.3-resilience-testing-–-placeholder} diff --git a/docs/operational-security-and-infrastructure-protection.md b/docs/operational-security-and-infrastructure-protection.md index 718b86e..83237e4 100644 --- a/docs/operational-security-and-infrastructure-protection.md +++ b/docs/operational-security-and-infrastructure-protection.md @@ -14,7 +14,7 @@ Service requests (bugs and issues) are reviewed by the sales and account manager ## **7.2 Data Security and Privacy** {#7.2-data-security-and-privacy} -We maintain a living document around data security and privacy, intended to regularly perform an internal audit or one with customers to validate our performance regarding data security and privacy. See [Data Security](https://docs.google.com/spreadsheets/d/1ZQamPOVlZD5hcV3vi7DTev9K7-b2bxa8?rtpof=true&usp=drive_fs) +We maintain a living document around data security and privacy, intended to regularly perform an internal audit or one with customers to validate our performance regarding data security and privacy. See [Data Security](https://docs.google.com/spreadsheets/d/1ZQamPOVlZD5hcV3vi7DTev9K7-b2bxa8?rtpof=true&usp=drive_fs) (restriceted access). ## **7.3 Identity and Access Management** {#7.3-identity-and-access-management} diff --git a/docs/performance-evaluation-and-retrospective.md b/docs/performance-evaluation-and-retrospective.md index 8ed7868..9fc3e49 100644 --- a/docs/performance-evaluation-and-retrospective.md +++ b/docs/performance-evaluation-and-retrospective.md @@ -10,7 +10,7 @@ OpenRemote has defined a series of KPIs to monitor the overall performance of th If relevant, improvement plans derived from the reviews are additionally monitored as part of the weekly meetings. In case of urgent corrective actions, they can also become part of project activities and their respective project reviews. -The Key Performance Indicators are part of a yearly [quality report](https://docs.google.com/presentation/d/1SQ44S_9UqY3gidl3je3oWDCApJw5vg9U?rtpof=true&usp=drive_fs) and include KPIs for Customer focus, Financials, People, Quality of processes and non conformity and Quality improvement. +The Key Performance Indicators are part of a yearly [quality report](https://docs.google.com/presentation/d/1SQ44S_9UqY3gidl3je3oWDCApJw5vg9U?rtpof=true&usp=drive_fs) (restriced access) and include KPIs for Customer focus, Financials, People, Quality of processes and non conformity and Quality improvement. ## **14.2 Internal Retrospective** {#14.2-internal-retrospective}