This Data Use Policy describes KWOTA’s use of Producers-related and Production Facility activity data and other relevant information as well as Client-related data. Data from Producers is a substantial part of KWOTA’s carbon credit creation process. It is the basis of establishing the Production Facility’s Secondary Material Baseline, Digital Verification Process and calculating verified CO₂ reductions. Therefore KWOTA ensures confidentiality, integrity, availability and resilience of the data as well as platform security.
The following technical and organisational measures are being provided in compliance with Article 32(1) of the GDPR. KWOTA maintains its production environment with Amazon Web Services and, as such, it relies in large part on the technical security measures adopted by Amazon Web Services. All physical security controls are managed by the cloud hosting providers we use. To the extent that KWOTA processes Personal Data outside the Amazon Web Services system, the following technical and organisational measures have been implemented with respect to your Personal Data. The structure of the content below is derived from Article 32(1) of the GDPR.
Data is encrypted both at rest and in transit. We use TLS encryption to protect the Data in transit and leverage industry-standard encryption tools to encrypt data at rest.
Platform Security
Physical access
KWOTA is a serverless environment and use the shared cloud security model. We do not run our own routers, load balancers, DNS servers, or physical servers.
A list of all cloud providers used to maintain security and provide services on our Platform can be found in our white paper located here.
Code reviews
All code is reviewed by a senior engineer before being deployed to production systems. Code reviews are designed to ensure the security, performance and quality of code released to production
User Logins
We protect our user login against a number of attack vectors including brute force attacks, by utilising third party services. Passwords are cryptographically hashed and salted based on industry best practises by our authorisation provider and user authorisation tokens to manage connections to the Platform.
Development Process
The deployment of the Platform is entirely automated. Changes to both infrastructure and code are subject to automated testing using our Continuous Integration (CI) tool before being released to production. A change that passes our review and testing process is then deployed to production using our CI tool.
Data encryption and transfer
KWOTA encrypts data both at rest and in transit. All network communication uses TLS encryption to protect it in transit. We leverage the encryption tools included in public cloud data stores to encrypt data at rest.
Overview
KWOTA is committed to protecting your information. While KWOTA has not undergone a 3rd party security audit for SOC-2 or ISO27001, 27018, we hold ourselves to the security controls present in those frameworks and have chosen our cloud hosting providers that are SOC and ISO compliant.
PCI Obligations
KWOTA is obligated to comply with PCI standards, and uses certified third-party payment providers (names) to achieve this. A copy of our compliance certification can be found here.
Employee Access to Data
KWOTA restricts access to systems and infrastructure to KWOTA personnel who require access as part of their job responsibilities. Access removal processes are used to revoke access to personnel who no longer need it.
KWOTA enforces a password policy and a requirement for multi-factor authentication when available to protect our accounts.
Change Control
We manage all our infrastructure as code, allowing us to audit and peer review any changes and to provide a secure and automated process for applying these changes.
Notification of Security Breach
KWOTA complies with GDPR requirements for data breach notification standards. In the event of a security breach KWOTA will take actions to contain, investigate and mitigate the breach. KWOTA will notify Clients in the event of a breach in writing within 72 hours of a breach being confirmed.
An unsuccessful Security Incident will not be subject to notification. An unsuccessful Security Incident is one that results in no unauthorised access to Personal Data or to any of ACG’s equipment or facilities storing Personal Data, and may include, without limitation, pings and other broadcast attacks on firewalls or edge servers, port scans, unsuccessful log-on attempts, denial of service attacks, packet sniffing (or other unauthorised access to traffic data that does not result in access beyond headers) or similar incidents.