Planton Genius security and architecture

Planton Genius is a multi-tenant web application for corporate greenhouse gas inventories. The client's team signs in through the browser, enters the period's activity data — energy, fuels, fleet, waste, travel, transport and other categories —, attaches supporting documents and submits them for internal review. The platform calculates emissions against a versioned emission factor base and returns the inventory, indicators and reports.

For the client's IT team, the starting point is this: in the default mode there is no integration — no agent installed on a workstation or server, no collector, no tunnel. Everything is entered through the interface, by named and individually authenticated people. When it makes sense to feed data collection from one of the client's own systems, integration is available today and is scoped as dedicated project work.

A cloud web application, with no component installed on the client's estate. Hosted on Oracle Cloud Infrastructure, Brazil Southeast — São Paulo. Processing and storage stay on Brazilian soil, which removes the need for an international data transfer arrangement under the Brazilian data protection act (LGPD).

Container architecture on managed Kubernetes, delivered via GitOps: images published to a private registry and applied to the environment by a synchronization controller. No change reaches production through manual server access — every change is versioned and recorded. External exposure happens through a single HTTPS entry point; the database and the attachment storage have no public address.

Ports and traffic direction

The last row applies only to clients who contract an integration, and it keeps the same direction as the others: the client initiates the connection, outbound.

The default mode has no integration: data is entered through the interface. When a client prefers to feed data collection from one of its own systems — ERP, fleet management, energy metering, invoice portals, logistics databases —, integration is available and is scoped as dedicated project work, designed together with the client's IT team before any rollout.

• The client pushes; Planton does not pull. The preferred arrangement is for the client's system to send data to the platform API over HTTPS, always outbound. In that shape the client network keeps no inbound port open, no VPN and no static IP.
• Alternative when pushing is not viable. An agreed file area — SFTP or the client's own repository — that the platform reads on an agreed schedule. Traffic direction, credentials and any network changes are defined in the integration scope and recorded in writing before rollout.
• Dedicated credential, minimum scope. Each integration gets a credential exclusive to that client, restricted to the agreed units and categories. It is never a person's credential, never a broad grant, and it can be revoked on its own.
• Nothing is discovered on its own. There is no scanning, no automatic system inventory and no reading outside the contracted, configured scope.
• Same trail, same approval. Data arriving through an integration is marked as such, with source, batch and timestamp, and goes through the same human review and approval as every other category.

Authentication is passwordless. The user enters their corporate email address and receives a six-digit one-time code, typed on the platform's own screen. The flow is driven by Planton's central identity provider over OIDC. It is a possession factor at login time: access depends on the corporate mailbox, which the client controls. There is no password to leak, reuse or age out.

The session is held in an httpOnly, Secure cookie, with limited validity and an absolute maximum horizon, ended at logout. Every write operation requires an application-specific header, which closes the CSRF surface.

• Individual identity, never shared. Each person has their own login tied to their corporate email. There is no generic departmental account.
• Role per scope. A role is granted over the whole organization or over a specific unit, and applies to the nodes below it in the hierarchy. Whoever is responsible for the São Paulo branch does not see the Rio branch.
• Least privilege, checked on every operation. Reading, filling in, reviewing and administering are distinct permissions. Writing to a data collection cell requires an explicit assignment in that campaign — holding the role is not enough.
• Administered by the client. An administrator named by the organization invites, assigns and revokes access on the platform, without depending on Planton. Every access change is recorded with author and date.
• Immediate revocation. Revoking access ends the link; an in-flight session loses validity at the next renewal cycle, measured in minutes.
• Optional controls. An IP allowlist, blocking at the entry point before the application, and federation with the client's corporate identity provider (Entra ID, Google Workspace or another OIDC/SAML provider) are available as configuration scope, assessed case by case.

The platform is multi-tenant: several contracting organizations share the same application. Isolation does not depend on the code remembering to filter — it is enforced by the database.

• Row-level filtering in the database. Every transaction runs with the user's identity and organization pinned to the connection context. Policies in the database itself restrict, row by row, what that transaction can see. A query without a valid context does not return another company's data: it fails.
• The organization does not come from the client. The link between user and organization is resolved on the server from the authenticated identity. A header or parameter tampered with in the browser does not change which company's data the request operates on.
• Separation by context. Each functional domain — organization, access, inventories, data collection, calculation — lives in its own database schema, with explicit boundaries between them.
• Attachments under the same cut. Supporting documents are held in private object storage with no anonymous read. Every download goes through the application and is authorized by the same rules as the interface.
• Planton team access. Technical support has named access, individually identified and explicitly flagged in the audit record — never anonymous, never in an automated background routine, and restricted to the people assigned to the project.

Confidentiality is covered by a specific clause in the service agreement, with a data protection annex. The clause sets out: client data is confidential; use is restricted to the contracted purpose; no sharing outside the declared subprocessor list; no use of the data to train models; return or deletion at the end of the contract.

• In transit. HTTPS is mandatory with modern TLS across the whole external path; termination happens at the entry point and internal traffic does not leave the cloud perimeter.
• At rest. Database and object storage volumes are encrypted by the cloud platform, with keys managed by the provider.
• No network exposure. Database and storage live in a private subnet, with no public address and no inbound route from the internet. The only path to them is the application.
• Secrets. Credentials and keys live in the cluster's secret store, never in code or container images, and can be rotated without an application change.
• Separate environments. Staging and production are distinct environments with distinct databases. Real client data exists only in production.
• Traceability. Authentications, access changes and actions on data are recorded with identity, timestamp and origin. Each data collection cell carries its full history — who filled it in, who submitted it, who approved or returned it, with what comment and when — and each calculated emission stores the methodology, the factor base version and the exact factor applied.

The platform has an assistant that supports data entry: it reads the documents the user attached, suggests the values it found and answers questions about the category at hand. It is typing and checking support, not a source of truth.

• The user decides. Every suggestion is presented for checking and can be edited or discarded. What enters the inventory is what the person confirmed, and approval remains with a human reviewer.
• Data scope. What travels to the model is the content of the documents and of the form for that data collection cell, at the moment the user invokes the assistant. There is no background scanning of the client's database.
• No training. Models are consumed through a corporate API, under an agreement that forbids using submitted content for training. The provider is listed among the subprocessors.
• Trail. Every assistant action that changes data is recorded as an action of the user who invoked it, with a timestamp.
• Optional. The assistant is enabled per organization and can be left switched off without affecting any other function.

Third parties that process client data on Planton's behalf in the operation of Planton Genius. The list is contractual: changes are communicated to the client before they take effect.

Inventory data stays in Brazil. The two providers outside the country process only what their function requires: the email address and message content, in the case of delivery; and the excerpt submitted by the user, in the case of the assistant.

The data processed in Planton Genius is predominantly operational — consumption, production, logistics. The personal data involved is limited to what is needed to operate access: name, corporate email address and a record of the user's actions.

In the processing relationship, the client is the controller of the data it enters into the platform and Planton acts as processor, handling that data according to the instructions documented in the contract and the data protection annex.

• Purpose. Data is used only for the collection, calculation, review and reporting of that organization's inventory.
• International transfer. Inventory data is processed and stored in Brazil. The exceptions are the two subprocessors listed above, restricted to the function described.
• Data subject rights. Requests for access, correction or deletion of personal data can be raised through the client's named contact and are handled within the statutory deadline.
• End of contract. Return or deletion of data as agreed, confirmed in writing.
• Contact. For data protection matters: [email protected]. This website's privacy policy covers processing on the institutional website, which is distinct from processing in the platform.

Material security incidents are communicated to the client's named contact, within the timeframe and in the form set out in the data protection annex, with what is known at the time of the communication and updated as the investigation progresses.

• Detection. Centralized metrics, logs and alerts, with an error dashboard monitored by the team. Application failures are caught by monitoring, not by a user report.
• Support. A channel defined in the contract, with ticket records: [email protected].
• Responsible disclosure. Found a possible vulnerability? Write to [email protected] with reproduction steps. We ask that you do not disclose publicly before contacting us, and we commit to responding and keeping you informed about the fix.

• Backup. The database has an automated backup routine with a defined retention period.
• Rebuild. The environment is rebuildable from the configuration repository: because delivery is via GitOps, the desired infrastructure state is versioned and does not depend on a hand-assembled server.
• Versioned delivery. Every code and configuration change goes through review, automated tests and a continuous integration pipeline before reaching production.
• Staging before production. Material changes are validated in a staging environment, with fictitious data, before promotion.

We would rather be exact about what we have today than imply a certification we do not hold.

• ISO 27001 / SOC 2. Planton is not certified today. The controls described on this page are the ones we operate, and they are available for documentary verification during vendor assessment.
• B Corp. Planton Soluções Sustentáveis Ltda. is a certified B Corp, headquartered in Porto Alegre, Brazil.
• Security questionnaires. We answer the questionnaires our clients' information security teams send. If your process uses a standardized format, send it through the contact below.

Much of a risk assessment resolves itself once you know what the system cannot reach. Except for the first row, the absences below are by design — the capability does not exist, it is not a switched-off setting.

• Architecture and security (PDF). This same information as a document to attach to your internal process. Public, no prior agreement needed.
• Data processing agreement (DPA). Available during contracting, as an annex to the service agreement.
• Completed security questionnaire. Sent on request, in the format your information security team uses.