Skip to content
Octo Inc. — Data Protection Unit
Octoberus DATA

CASE — WE AUDITED OURSELVES FIRST

We practice what we sell

Octoberus runs physical-security platforms for energy and telecom clients. Before offering Law 21,719 compliance to others, we applied the same methodology to our own systems. Here is the summary — with no sensitive detail.

WE RAN OUR OWN TOOL ON OURSELVES

From diagnosis
to a system in operation.

Like any company, we didn't start perfect: our own assessment found real critical areas. The difference is what we did with that result — we fixed the highest-impact items immediately and put a data-protection system into operation, with a roadmap to December 1, 2026. That's what we deliver to our clients too.

4

COMPONENTS AUDITED

13

FINDINGS PRIORITIZED

6

CONTROLS IN OPERATION

The scope

Four components, one methodology.

Services API

Backend governing users, access and media

Web console

The clients' operations interface

Mobile app

Door opening via Bluetooth, PIN and QR

Firmware

Physical door and gate devices

READ-ONLY REVIEW · NO ACCESS TO PRODUCTION DATA · NO TESTS AGAINST LIVE SYSTEMS

What we found

Categories of findings.

We classified each finding by its exposure under the law (minor, serious, very serious). Here are the categories, in aggregate — the technical detail lives in a restricted report, never in public.

01

Sensitive data

Facial recognition and biometrics with no defined lifecycle: the law's most demanding category.

02

Internal logs

Full personal data written in clear text into audit logs.

03

API surface

API origins without restriction.

04

Crash reports

Secrets and personal data sent to third-party services without scrubbing.

05

On-device storage

Credentials and sensitive data unencrypted in the app.

06

Retention

No deletion policy: everything was kept indefinitely.

The actions, concretely

What we did, technically.

It's not enough to say "we improved security." These are the concrete measures we applied — described with no exploitable detail, but specific enough to show the real work.

On the access platform

Redaction of personal data in logs

The audit log now strips secrets and masks identifiers (national ID, phone, license plate) before storing. The password is never written to a log.

Restricted API origins

Only authorized domains can call our APIs; requests from unknown origins are shut out.

Secrets out of crash reports

The app stopped sending the device key and door PIN to the third-party services that receive error reports.

Telemetry & credentials by environment

We moved the telemetry endpoint and signing credentials out of the code; they are now injected per environment, with rotation documented.

Security foundations, in operation

Encryption in transit & at rest

End-to-end HTTPS/TLS and databases encrypted at rest.

Strong password hashing

Stored with bcrypt; never in plain text or in logs.

Least-privilege role-based access

Each user and each service accesses only what it needs (RBAC).

Secrets in a managed vault

Service credentials live in a secrets manager, outside the code.

Public surface & email

Real cookie consent

Analytics only load after the person accepts (Consent Mode v2).

Email domain authentication

We published SPF, DKIM and DMARC (quarantine) to stop spoofing of our email.

Layered anti-bot on forms

Captcha-style verification, a honeypot and rate limiting to stop automated spam.

DNS cleanup

We removed stale DNS records a third party could have claimed (subdomain-takeover risk).

How we deploy

Deploys with no static keys

Our automation uses temporary federated identity (OIDC): there are no stored access keys.

Protected main branch

Every change goes through review and an automatic check before it ships.

What required database changes, business decisions or infrastructure validation went into a prioritized roadmap — the same structure we deliver to our clients: fix what's safe now, plan the rest in order.

The system we implemented

Framework-aligned, with a roadmap.

Data protection isn't a report: it's a system that runs every day, organized around the frameworks your clients recognize, with a roadmap toward December 1, 2026.

Aligned to frameworks your clients recognize

Access control

SOC 2 CC6 · NIST PR.AA · ISO A.8

Encryption

SOC 2 CC6 · NIST PR.DS · ISO A.8

Incident response

SOC 2 CC7 · NIST RS/RC · ISO A.5

Third-party risk

SOC 2 CC9 · NIST GV.SC · ISO A.5

SOC 2 · NIST CSF 2.0 · ISO/IEC 27001 AS THE MATURITY NORTH STAR

ROADMAP TO DEC 1, 2026

  • 01 Field-level encryption of the door PIN and biometric data.
  • 02 Impact assessment (DPIA) of biometric and facial processing.
  • 03 Retention policy with automatic deletion once the purpose ends.
  • 04 Data-subject rights: export and effective erasure per person.
  • 05 Breach-notification procedure, with an annual drill.
  • 06 Formalized Record of Processing Activities (RoPA).

We're transparent about what's still in progress. An honest program with dates is more credible than a claim of absolute compliance — that's how we deliver it to our clients too.

WHY IT MATTERS

Anyone can sell a report. We went through the full process — assessment, remediation and roadmap — on real systems running critical infrastructure. We know where it hurts because it hurt us first.