Certified and sustainable IT security
GDPR-compliant file and data management with a focus on data protection.
 |
 |
- Kontainer is operated in a private cloud in 3 data centers in the EU, sustainability powered by 100% hydroelectric or wind energy generated. Kontainer is designed to run via microservices in a scalable microservice cluster. All files are stored in a mirrored object storage in two data centers with redundant setup and failover plus the third location for backup. All services are divided into network segments, and there is advanced intrusion prevention on all network traffic.
- In front of all servers, there is an effective DDoS filter on all traffic. At the network, entrance is a firewall cluster with IDP scanning of all traffic. Firewall security rules are reviewed continuously. All logs and suspicious traffic are reviewed, and action is taken if needed. All network equipment has scheduled firmware updates.
- All applications Kontainer use are updated in scheduled procedures, suspicious operations on Kontainer are reviewed, and action is taken if needed.
- Kontainer is IT audited annually by Price Waterhouse Cooper’s and certified with an ISAE 3402 built on security controls from ISO 27001 in terms of GDPR on software and network.
Contact us to learn more about our ISAE 3402 certification.
Backup and restore
Kontainer ensures comprehensive data backup and long-term availability.
- All data is backed up once a day and stored for 90 days.
- All files are mirrored between the 2 data center continuously.
- It is possible to extra off site backup.
Scalability and compatibility
Kontainer relies on flexible microservices and expandable storage technology.
- The solution is built up via microservices. All microservices run in a service cluster. This means that all individual parts are very easy to scale up and down as needed.
- Storage makes use of object technology and can also be scaled up to very large amounts of data.
- The default access to Kontainer is via a standard browser. Kontainer currently supports Chrome, Safari, Edge and Firefox. The system is constantly updated to support the latest browsers. Older browser support is similarly removed where needed.
GDPR-compliant maintenance
Kontainer offers reliable support, maximum availability, and a stable system architecture.
 |
 |
- Phone, chat and e-mail support for administrators:Â Yes
- 24-hour monitoring and platform maintenance:Â Included
- Hosting and ongoing upgrades and new features:Â Included at package level
- Possibility of continuously upgrading and downgrading the package:Â Yes
- Uptime:Â 99.9%
- Full Restful API: YES
- Private Cloud operated in 2 data centers with redundant environment and failover:Â Yes
- GDPR– and NIS2-compliant: Yes
- Controls after SOC2-standard: Yes
Secure, encrypted operation
Kontainer relies on multi-layered network security and modern encryption standards.
 |
 |
All microservices and storage is separated in vlans. All access to the platform from outsite firewall is through https based on TLS 1.2. Traffic between firewall and main proxy server is encrypted by https based on tls 1.2.
- Global Ddos filter
- Firewall with advanced filtering and packet inspection
- Frontend security proxy layer for all incoming traffic
- When using SSO: Transfer via SAML
Response time
All standard calls in Kontainer are less than 1 second. Advanced searches may take up to 3 seconds.
It is also possible to download files via WebDav or via the plugins for Microsoft Office and Adobe applications.
The following response times will apply:
- Login page: < 1 sec
- Login: < 2 sec
- Folder list: < 2 sec
- Attribute modification: < 1 sec
- Search: < 3 sec
- Advanced search: < 3 sec
- Edit metadata: < 2 sec
- View medata: < 2 sec
The speed of data transfer depends on the speed of the download connection. At 1 gbit, the download speed is about 100 MB / s.
Https is used for all file transfers. File transfers can be done either via browser interface or via API call.
Kontainer deployment procedures
When Kontainer develops and deploys new releases, it will be performed in the following steps:
- Tickets are created in Jira and specified before start-up. All tasks are split up so that they take a maximum of 14 days and are included in Kontainers 14-day development sprints.
- Project managers specify, prioritize, and plan all sprints.
- After development of tickets, all code is sent for internal code review before bugfixes, or feature additions are released on Kontainers internal develop/test server
- Unit tests are performed automatically on all code changes. New code cannot be released on the test servers if the code cannot pass a unit test.
- When finished tickets are merged and tested by the developers on the internal develop / test server.
- After internal test the bugfixes / additional features are released on Kontainers internal Staging server for final manual testing by the test team.
- The same code can be deployed simultaneously on a Customer specific staging server for approval.
- When staging is approved, the corrections are deployed live (without downtime)
- Live server setup is tested manually with all corrections after final release.
- If something goes wrong against expectations, releases can be rolled back (without downtime)
- All bugfixes and additional features documentation is described in an internal change.log file.
Customer specific test server and procedures
Communication to the customer about releases
- Releases that affect the customer’s workflows or integrations are notified at least 5 days before release.
- Minor optimizations, minor new features and bug fixes that do not affect the customer’s workflows are released without the customer being notified.
- Administrators at the customer will receive email notifications about upcoming new features in the roadmap.
If a customer wants a specific test staging server to test major updates or updates related to customer specific integrations or primary workflows before these live releases this can be added.
In the case of a customer specific test environment, the customer will be notified at least 2 working days before releases come for testing on the customers ‘own test server.
The customer then has 5 days to test fixes/addons on the staging server. If fixes/addons are approved, they will be deployed live, if they are not approved, there will be a new test round on the customer specific test server as soon as the corrections are made. All test rounds will have the same notification intervals. When deploying new releases on live there will be no down time.
Before start-up, it is specified in collaboration with the customer which type of tasks can be defined as critical integrations and Major updates
There is an additional price for customer-specific test server