Import initial version of handbook from Google doc

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 |

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.

docs/annexes/index.md

@@ -0,0 +1,7 @@
+---
+sidebar_position: 17
+---
+
+# Annexes
+
+This section contains supporting annexes for the OpenRemote Quality Handbook.

docs/business-continuity-and-operational-resilience.md

@@ -0,0 +1,56 @@
+---
+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) (restricted access).
+
+## **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.
+
+The results of these tests are documented and used to improve resilience planning.

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.

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](./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.
+
+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.

docs/data-protection-and-privacy-management.md

@@ -0,0 +1,27 @@
+---
+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** {#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.
+
+Requests are handled through defined procedures and documented accordingly.