Trust & Security
Greenstamp handles tax certificates, fiscal filings, and financial records on behalf of businesses across Mexico and Latin America. Here is a plain-English account of the technical controls we use to protect that data.
Last reviewed June 2026Data Encryption
Greenstamp uses Lockbox (AES-128-GCM) to encrypt sensitive database columns. Encrypted fields include bank-feed OAuth tokens, multi-factor authentication secrets, and personally identifiable contact information (phone, email). Deterministic encryption is used where indexed lookups are required, preserving query capability without exposing plaintext.
A single master key, stored as an environment variable, is required in production. The application refuses to start without it. Sensitive values — passwords, tokens, API keys, certificate material, OTP codes, CVV, and SSN-type fields — are filtered from all logs and error reports before they reach any storage or monitoring system.
All traffic between clients and Greenstamp servers is carried over TLS. The application enforces HTTPS in production and sets a Strict-Transport-Security header to prevent protocol downgrade. Secure and HttpOnly flags are set on session cookies.
Certificate & Key Handling
Mexico's SAT requires businesses to sign fiscal documents (CFDIs) with a Certificado de Sello Digital (CSD). Greenstamp stores certificate files and forwards them to an authorized PAC (Proveedor Autorizado de Certificación) over TLS for signing. Certificate material is never logged.
The application monitors certificate validity and notifies account administrators at configurable intervals before expiration. Expired or invalid certificates are flagged in the audit log and trigger user notifications, reducing the risk of compliance gaps from unnoticed expirations.
CSD and FIEL certificate files are stored encrypted at rest using AES-256 (Rails ActiveRecord Encryption), the same mechanism protecting private keys and passwords alongside them. Certificate bytes are never written to disk in plaintext. Signing requests are forwarded to SW Sapien, an SAT-authorized PAC, over TLS.
Access Control & Tenant Isolation
Greenstamp is a multi-tenant application. Every database model that holds customer data is scoped to a tenant entity using acts_as_tenant — a library that automatically appends a tenant condition to all queries. Records belonging to one organization are never returned in queries for another.
Authorization is enforced on top of tenant scoping via Pundit, a policy-based authorization library. Every controller action that touches a resource calls an explicit policy check. A global rescue handler returns 403 Forbidden for any unauthorized access attempt; there is no silent failure. Each user operates within one of three roles:
Read-only access to records within the user's assigned entities. Cannot create, modify, or delete any data.
Day-to-day write access: create invoices, process payments, manage counterparties. Cannot alter account settings or billing.
Full access including user management, billing, and organization settings. Recommended only for designated account owners.
Scoped to specific read or write permissions. Stored as SHA-256 digests — the raw token is shown only once at creation. Keys expire on a configurable date.
Cross-tenant operations (for example, background jobs that process data across all organizations) temporarily suspend the tenant scope and re-establish it explicitly. Each such bypass is documented in code and confined to the specific entities it needs to touch.
Authentication
User passwords are hashed with bcrypt at a cost factor of 12 in production. Accounts are locked after 5 consecutive failed login attempts and automatically unlock after 1 hour.
TOTP multi-factor authentication (compatible with Google Authenticator, Authy, and any RFC 6238 app) is available to all users and can be made mandatory for all members of an organization by an administrator. MFA secrets are generated with a cryptographically random seed and stored encrypted (Lockbox). Ten single-use recovery codes are issued at enrollment; each is bcrypt-hashed and consumed on use.
Sessions expire after 2 hours of inactivity. Password reset tokens are valid for 6 hours. Email changes require re-confirmation at the new address before taking effect.
Infrastructure
Greenstamp runs on Render in the US East region. The application database and object storage remain within that region.
The database is backed up daily with a 7-day retention window. Backups are managed by Render and stored separately from the primary database.
Webhooks & Integrations
Greenstamp receives event webhooks from payment processors, e-commerce platforms, and accounting systems. Every inbound webhook endpoint verifies the request signature before processing the payload. Verification uses HMAC-SHA256 with constant-time comparison to prevent timing attacks. Endpoints with unverifiable signatures reject the request before any data is touched.
| Provider | Verification method |
|---|---|
| Shopify | HMAC-SHA256 via X-Shopify-HMAC-SHA256 header |
| Stripe | Stripe SDK Webhooks.construct_event signature check |
| Square | HMAC-SHA256 via X-Square-HMACSHA256-Signature header |
| Intuit / QuickBooks | HMAC-SHA256 via Intuit-Signature header |
| Mercado Pago | Manifest HMAC-SHA256 with timestamp validation |
| Storecove (PEPPOL) | HTTP Basic Auth or custom header with constant-time compare |
Audit Logging
Greenstamp maintains a structured audit log of security-relevant events, including user sign-in and sign-out, API key creation and revocation, user provisioning and deactivation, and password reset requests. Each log entry captures the IP address, user-agent, HTTP method, response status code, and an immutable snapshot of the actor's role and organization at the time of the action.
Log entries are scoped to their tenant entity for data isolation. Events originating from background jobs, webhook deliveries, console sessions, and API requests are distinguished by context type so that automated and human actions are separately attributable. Logs are retained for a minimum of 90 days.
Data Retention & Deletion
Mexican law requires that CFDIs (digital tax receipts) be retained for a minimum of five years after the fiscal year in which they were issued. Filed CFDIs, their XML representations, and associated payment records are never permanently deleted. Greenstamp enforces this in code: the retention job that purges soft-deleted records explicitly excludes any record with an associated fiscal filing.
Records that are not subject to fiscal retention — draft invoices that were never filed, imported contacts, templates, and similar operational data — are soft-deleted when removed by a user and permanently purged after a 90-day holding period.
Account closure and data deletion requests can be submitted to privacy@greenstamp.io. Requests are processed within 30 days and do not affect records subject to mandatory fiscal retention.
Integrations & Subprocessors
The following third-party providers process or store customer data on behalf of Greenstamp. Customers may request the current subprocessor list at privacy@greenstamp.io.
| Category | Provider | Purpose |
|---|---|---|
| Cloud hosting | Render | Application servers, database, object storage (US East) |
| PAC provider (CFDI stamping) | SW Sapien | SAT-authorized CFDI certification and stamping |
| E-invoicing network | Storecove | PEPPOL / international e-invoice delivery |
| Payment processing | Stripe | Subscription billing |
| Bank feed connectivity | Belvo, Plaid | Read-only bank transaction import |
| AI assistant | Anthropic (Claude) | In-app AI features; governed by Anthropic's data processing agreement |
| Transactional email | ActiveCampaign | Invoice delivery, notifications, password reset |
Dependency & Code Security
Every pull request runs three automated security checks before it can merge:
Static analysis for common Rails security vulnerabilities including SQL injection, XSS, and mass-assignment risks.
Scans Gemfile.lock against the Ruby Advisory Database for known CVEs in application dependencies.
Audits JavaScript dependencies pinned via import maps against known vulnerability databases.
Rack::Attack throttles login, MFA, password reset, and public endpoints. Login is limited to 5 attempts per 20 seconds per IP address.
Compliance Roadmap
Greenstamp currently does not hold a SOC 2 Type II attestation or ISO 27001 certification. We are building toward these milestones as the product scales:
SOC 2 Type II — We are targeting completion of a SOC 2 Type II audit within the next year. Auditor selection is in progress.
Penetration test — A third-party penetration test and OWASP assessment is planned within the next three months. Testing firm selection is in progress. Results will be made available to enterprise customers under NDA on request.
Partners and enterprise customers who require security documentation before onboarding are welcome to contact us at security@greenstamp.io. We can provide a completed security questionnaire, architecture overview, and data processing agreement on request.
Responsible Disclosure
If you discover a security issue in Greenstamp, please report it to security@greenstamp.io before disclosing it publicly. We will acknowledge your report within 2 business days and work with you to understand the issue and coordinate a fix.
We ask that you give us a reasonable window to investigate and remediate before any public disclosure, and that you avoid accessing, modifying, or deleting data that does not belong to you. We do not operate a paid bug bounty program at this time, but we recognize researchers who report valid issues responsibly.
Our /.well-known/security.txt
file follows RFC 9116 for automated security tooling.