Security & architecture

How Green Click keeps every tier’s data apart

What the platform does today to isolate tenants, control access and protect vendor credentials. Everything on this page is in the code. None of it is a certification.
Chain model

One tree, and every query stays in its branch

Every organization sits at one point in the chain. It sees itself and everything below it, never anything beside it or above it.
Sees this tier and everything below it. Siblings never see each other. A record outside your branch returns 404, so its existence is not confirmed either.
Order lifecycle

From order to invoice, every step on the record

Customer orders go through approval first. Provisioning runs as a background job that is safe to retry, and every vendor call it makes is logged.
  1. Draft
  2. Approval pending
  3. Approved
  4. Confirmed
  5. Provisioning
  6. Active
Other states
  1. Rejected
  2. Suspended
  3. Cancelled
  1. Month close
  2. Draft invoice
  3. Your sign-off
Controls

What protects an account today

Argon2 password hashing

Passwords are hashed with Argon2, the winner of the Password Hashing Competition.

Two-factor authentication

Time-based one-time codes (TOTP) from any authenticator app.

Short-lived sessions

Access tokens expire after 15 minutes. Refresh tokens last 7 days, rotate on every use, and the old one is revoked.

Login rate limiting

Sign-in attempts are throttled to 10 a minute.

Permission-based access

Every API action checks a named permission. Each tier has a system role, and a role holds only the permissions it lists.

Tenant isolation

Every list and every lookup is filtered to the caller’s branch of the chain, so a query cannot return another tenant’s records.

Audit log

Who did what, and when, for every action. Retention is set by the platform administrator, 400 days by default.

Impersonation on the record

When support acts inside an account, it is logged against both the operator and the account.

Encrypted credentials

Credentials of provisioned services and Vultr API keys are encrypted at rest with Fernet (AES-128 with HMAC-SHA256).
Provider API logs

Every vendor call, attributed and redacted

Each call to a vendor API is stored with the customer, order and user behind it. Authorization headers, API keys, tokens and passwords are masked before anything is written.
Not on this page
Hosting, sub-processors and data-residency details are available on request, in writing. Our data processing terms are public.
ProviderApiLogIllustrative entry
{
  "provider": "Vultr",
  "action": "Create instance",
  "product": "Cloud Compute · 2 vCPU / 4 GB",
  "organization_name": "Harbor IT",
  "organization_type": "CUSTOMER",
  "user_email": "[email protected]",
  "method": "POST",
  "endpoint": "/v2/instances",
  "status_code": 202,
  "success": true,
  "exec_ms": 412,
  "request_headers": {
    "Authorization": "••••••••",
    "Content-Type": "application/json"
  },
  "request_body": {
    "region": "fra",
    "plan": "vc2-2c-4gb",
    "user_data": "••••••••"
  },
  "correlation_id": "ord_7f3c1e"
}

Have a security questionnaire?

Send it to us and we will answer it in writing.