Foundation Build Trust Centre

How we protect the integrity of our foundation builds.

Last updated: 22 April 2026

Overview

Kongo delivers multi-month HubSpot implementations — projects that touch sensitive client data, configure business-critical automation, and often run across multiple teams. This page explains how we protect the integrity of that work.

Delivery method

Every engagement is anchored by a set of foundation build documents — one per hub (CRM, Sales, Marketing, Service) — amounting to roughly 80 sections of configuration work. Before we start, each section is classified into one of three delivery modes, so you know exactly how every item will be built.

Automated

API-driven configuration

Configuration created programmatically via HubSpot's public API. Deterministic, reviewable, and deployed from a version-controlled repository.

Hybrid

Automated plus human step

Automated where possible, with a consultant completing the final step. Used for data imports, complex workflow branches, and any item where part of the work benefits from human judgement.

Manual

Consultant in the platform

Configured directly by a Kongo consultant in the HubSpot UI. Used where the API doesn't cover the task, and always where the task has real-world consequences — user invites, OAuth connections, billing changes.

You receive this classification as part of your foundation build sign-off. No delivery mode is a surprise.

Traceability

Every configuration change we make to your portal is committed to a private Git repository dedicated to your engagement — properties, pipelines, workflows, lifecycle stages, custom objects, and data imports. The repository is the canonical record of what was built and when.

Each change is stored as JSON in HubSpot's API v3 format, alongside a changelog entry recording what changed, when, why, and by whom. Every commit has an author and a reviewable diff.

You can request a copy of your audit trail at any time.

Credentials & access

Your credentials never sit in a repository, a spreadsheet, or a chat tool. They live in a dedicated secrets vault, scoped per engagement, and retrieved only at the moment of use.

  • Encrypted at rest. Credentials are stored in AWS Secrets Manager in Sydney (ap-southeast-2), one secret per engagement, encrypted by the platform's managed keys.
  • Private App tokens, not passwords. We authenticate into your portal via a HubSpot Private App token that you generate and share once. We do not store user passwords.
  • Scoped IAM access. Only the Kongo team assigned to your engagement has permission to retrieve your credentials. Access is scoped to your specific secret — never a wildcard.
  • Time-boxed local access. No long-lived access tokens sit on any team member's machine. Access is re-established per session with a local biometric or password unlock, and expires automatically.
  • Anomalous-access alerting. Retrieval of your credentials outside expected working hours, or from an unrecognised identity, triggers an automated alert to Kongo's security channel.

You can rotate your credentials at any time — we'll re-authenticate on next use.

Review model

Our delivery splits into two explicit roles. A builder implements changes against your portal. A reviewer validates the work before any claim of completion — against the foundation build plan and against the deployed state of your portal, not the builder's word.

A change is recorded as shipped only when it exists in your engagement repository and there is evidence it reached the deployed system. If code changed but the underlying issue remains, we record it as changed but not solved — never hidden.

Quality controls

Five controls we apply to every engagement.

  1. Sign-off before configuration. Foundation build documents are approved in writing by you before any configuration work starts.
  2. Workflows inactive by default. Every workflow is delivered in an inactive state. We activate only after you've reviewed and accepted it in UAT.
  3. UAT as a deliverable. A dedicated UAT plan is provided before go-live, covering each configured item.
  4. Evidence-based completion. Configuration changes are proven against your portal — actual API verification — before being marked complete. Claims without verification are rejected.
  5. Pilot before cut-over. Data migrations run through a small, representative pilot first. You approve the pilot before any full cut-over runs. One-off migration scripts are flagged as single-use, so no one can accidentally re-run a completed migration.

Rate limits are respected on every API call, with exponential backoff on retries — your portal's capacity stays available for your own integrations and workflows.

End of engagement

When your implementation ends, your HubSpot credentials are rotated or revoked at your instruction. We remove or archive the stored secret.

You retain full administrative ownership of your portal. Kongo does not require ongoing access after the engagement closes.

The configuration audit trail for your engagement — the Git repository of every change we made — is retained indefinitely as your service record, unless you request deletion in writing. A copy is available on request at any time.

If the relationship continues into ongoing support, we establish a new scope, new access, and new credentials. Prior implementation access does not carry over.

Frequently asked questions

Questions we hear most often from procurement and security reviewers.

Who on the Kongo team has access to our portal during an engagement?

Only the specific consultants assigned to your engagement. Access is scoped to your individual secret in our secrets vault — no Kongo team member has blanket access to every client.

Do you use browser automation against our portal?

No. All automation we run against your portal uses HubSpot's public API with Private App authentication, in line with the Partner Agreement, Developer Terms, and AUP. Where automation isn't possible via the API, a Kongo consultant configures the item directly in the UI.

How do you authenticate into our portal?

Via a HubSpot Private App token that you generate and share once. We never request or store user passwords. The token is stored encrypted in our secrets vault.

Do you use AI agents?

Yes, within defined boundaries. We use agent tooling to generate configuration payloads, write API calls, and propose changes — all of which execute against HubSpot's public API. The agent never logs in as a user, never runs a browser against your portal, and never operates outside our defined execution skills. A Kongo consultant reviews every output before it deploys.

Can we see the audit trail while the engagement is live?

Yes. A copy of the configuration audit trail for your engagement is available on request at any time.

Where is our data stored?

Your HubSpot Private App token is stored encrypted in our secrets vault, located in Sydney. Your portal data stays in your HubSpot portal — we do not copy, export, or persist your CRM records in any Kongo system.

What happens to our credentials when the engagement ends?

Credentials are rotated or revoked at your instruction. The stored secret is removed or archived. You retain full ownership of your portal; we don't require ongoing access.

What if a configuration change causes an issue in our portal?

Every change is recorded in the engagement Git repository, making rollback or diagnosis straightforward. Workflows are delivered inactive by default so automation doesn't start running until you've approved it in UAT. For data migrations, we pilot before we cut over.