As a Software as a Service platform, BRYTER is in continuous development. This includes adding new functionality, as well as maintaining existing features by implementing the latest technology and fixing malfunctions, known as bugs.
Incident Management
In case of timeouts, bugs or other issues, BRYTER's development team follow rules based on malfunction classes. A malfunction class determines the impact of the incident and the appropriate recovery or fix of the malfunction. If you notice a malfunction, please report it to support@bryter.io.
Response and recovery times
Response times
- For Malfunction Class 1: 1 hour
- For Malfunction Class 2: 2 hours
- For Malfunction Class 3 to 5: 4 hours
Recovery times
- For Malfunction Class 1: 4 hours
- For Malfunction Class 2: 8 hours
- For Malfunction Class 3: 24 hours
- For Malfunction Class 4 & 5: Next scheduled maintenance date which happens on a weekly basis
Backups: Every 24 hours
Malfunction Classes
Malfunction Class 1
The Malfunction means that the Service as a whole or significant functions required or intended to be used by the Customer to perform critical business processes cannot be used (e.g. all or essential functionalities of the applications described in the performance description are not available; a workaround solution is not possible).
Malfunction Class 2
Use of the Service or essential functions is significantly impaired or limited (e.g. applications are not available to entire organizational units, or only to a very limited extent; a workaround solution is not possible).
Malfunction Class 3
Same as Malfunction Class 2; however, a reasonable workaround solution exists which can be implemented by the Customer within a reasonable period of time (e.g. applications are not available to individual users or only to a very limited extent; a workaround solution is not possible).
Malfunction Class 4
The use of the Service or essential functions is only insignificantly limited or it is a limitation of non-essential functions (e.g. field designations in an application are faulty without this leading to faulty operation by the customer. Bypass solutions for Malfunction Class 1-3).
Malfunction Class 5
Insignificant malfunctions (e.g. typing Malfunctions, editorial malfunctions and similar malfunctions without affecting the functionality of the Service).
Planned unavailability and scheduled maintenance
In times of planned unavailability, the provider is entitled to maintain and update applications and/or servers, perform data backups or other planned work. Planned non-availabilities must be agreed with the customer in advance. Regular maintenance takes place in a planned rhythm of approximately every 8 weeks and is notified to the customer in text form at least five (5) working days in advance. Where possible, maintenance is carried out at times of low workload, preferably at night and at weekends. During the regular maintenance times, the applications cannot be used or can only be used to a limited extent.
Information regarding RTO / RPO
RTO depends on the scenario. In the worst-case "AWS disaster scenario" where our AWS account has been compromised or our setup inside AWS has sustained critical damage, and we need to recover from offsite backups, our RTO is up to 36 hours to completely rebuild all relevant services and restore from backup.
RPO in the worst-case disaster recovery example above is limited by the time of the last offsite backup and is therefore up to 24 hours.
Version control
BRYTER's development is based on a version control system (Git) where all code changes are committed. For every change, a separate code branch is created. All merges to the master branch must be approved by an authorized person, after undergoing thorough testing and confirmation that all defined acceptance criteria are met.
Changes in the development and during the maintenance of the systems must be done according to the Change Management Policy.
Repository
All code and all other files related to development are kept in the company’s code repository, and are protected from unauthorized access and unauthorized change.
Secure development and maintenance
Risk assessment for the development process
In addition to the risk assessment performed according to the Risk Assessment and Risk Treatment Methodology, our Chief Product Officer periodically performs the assessment of the following:
- Risks related to unauthorized access to the development environment
- Risks related to unauthorized changes to the development environment
- Technical vulnerabilities of the IT systems used in the organization
- Risks a new technology might bring if used in the organization
Securing the development environment
Access to the development environment is restricted only to authorized employees. Testing and production environments are separated. Backups are made on a regular basis based on the backup policy.
Secure engineering principles
Our Chief Product Officer issues procedures for secure information system engineering, both for the development of new systems and for the maintenance of the existing systems, as well as setting the minimum security standards which must be complied with.
The same secure engineering principles will be applied to outsourced development, and defined through the contracts as defined in the Supplier Security Policy.
Security requirements
When acquiring new information systems or developing or changing existing ones, our Chief Product Officer documents security requirements in the Security Requirements Specification.
Security requirements related to public networks
Our Chief Product Officer is responsible for defining security controls related to information in application services passing over public networks:
- The description of authentication systems to be used
- The description of how confidentiality and integrity of information is to be ensured
- The description of how non-repudiation of actions will be ensured
Our Chief Product Officer is responsible for defining controls for online transactions, which must include the following:
- How misrouting will be prevented
- How incomplete data transmission will be prevented
- How unauthorized message alteration will be prevented
- How unauthorized message duplication will be prevented
- How unauthorized data disclosure will be prevented
Checking and testing the implementation of security requirements
Our Chief Product Officer is responsible for defining the methodology, responsibilities and the timing of checking whether all the security requirements from the Security Requirements Specification have been met, and whether the system is acceptable for production.