Security & data
Rehnable was designed around one non-negotiable rule: no customer CRM data at rest on our infrastructure. Everything on this page follows from that decision — including the things we cannot do because of it.
Principles
Contacts, companies, deals and activity are fetched live for the chart you have open, held in your browser, and gone when you close it. We never copy your CRM into our database — there is no sync, no cache of contact records, no nightly export.
Every HubSpot API call is made by our backend. The editor talks only to our API and never holds a HubSpot access token, so a compromised browser extension or an XSS bug on our page cannot walk away with portal credentials.
No API keys and no shared credentials. Rehnable asks only for permissions it actually uses, every one of them justified in the table below, and adding a permission is a deliberate decision rather than a convenient side effect.
The editor session starts from a request HubSpot itself signed. We verify that signature server-side and issue a short-lived, single-use launch token. A portal ID pasted into a query string proves nothing and is never trusted as identity.
Data
This is the complete list, not a summary. If something is not in the left column, it is not in our database.
| Encrypted OAuth refresh token Encrypted with AES-GCM; key held in Azure Key Vault |
| Portal ID and install status Which portal installed the app, and when |
| Association type IDs The numeric IDs of the Manager / Direct report labels in your portal |
| Portal settings Team colours, card property choices |
| Seat assignments HubSpot user IDs that hold a seat |
| Subscription status A Stripe reference and whether it is active — no card data |
| Operational logs Errors and request metadata, without CRM payloads |
| Contact records, names or email addresses |
| Company records or company properties |
| Deals, amounts, stages or forecasts |
| Emails, calls, meetings or any activity content |
| The org chart structure itself — it lives in your portal as associations |
| Team assignments — they live on your contacts as a property |
| Payment card details — Stripe handles those, we never see them |
A consequence worth stating plainly: if our database were fully compromised, an attacker would learn which portals use Rehnable and which users hold seats. They would not obtain a single one of your customers' records.
Permissions
HubSpot shows this list during installation. Here is what each permission is for, in plain language, so a security reviewer can judge it without reverse-engineering the consent screen.
| Permission | Used for | Without it |
|---|---|---|
| Read contacts | Loading the people associated with a company, their names, titles, buying roles and activity timestamps | Nothing works |
| Write contacts | Creating and archiving the Manager / Direct report associations, and writing team values | The chart is read-only |
| Write contact schema | Creating the orgchart_team property once, at install |
Teams cannot be used |
| Read companies | The company you opened, and the parent/child structure in the group view | Nothing works |
| Write company associations | Re-parenting companies in the group view | The group view is read-only |
| Read deals | Counting each contact's deal participation for the heatmap | Deal heat is unavailable |
| Write lists | Creating a static list from a selection, when you ask for one | The list action is unavailable |
| Read users | Showing your portal's users so an admin can assign seats to real people | Seats cannot be assigned by name |
| Read owners | Populating the assignee picker when creating tasks | Tasks cannot be assigned |
What is deliberately absent: no access to email content, no marketing or CMS permissions, no ability to delete contacts, companies or deals, and no background access when nobody is using the app. Rehnable reads when a user opens a chart and writes when a user changes something.
Access flow
The app card on the company record calls our backend through HubSpot's own fetch mechanism, which signs the request.
The backend validates HubSpot's signature before doing anything else. That is what establishes portal, user and record — not the URL.
A single-use token, valid for under a minute and bound to that portal, user and record, is handed to the card.
The editor swaps the token for a session and starts making API calls — always to our backend, never to HubSpot directly.
Access is checked on every launch, not just at install: the portal must have an active install, and your user must hold a seat. Uninstalling the app or removing someone's seat takes effect on their next attempt to open the editor.
Infrastructure
| Component | Provider | Region | What it holds |
|---|---|---|---|
| Application (API + editor) | Microsoft Azure — Container Apps | Sweden Central (EU) | Nothing at rest |
| Database | Azure Database for PostgreSQL | Sweden Central (EU) | Encrypted tokens, portal config, seats |
| Key management | Azure Key Vault | Sweden Central (EU) | The encryption key for refresh tokens |
| Billing | Stripe | Per Stripe's own infrastructure | Payment and subscription data — no CRM data |
| Your CRM data | HubSpot | Your portal | Everything — it never leaves |
The API and the editor are served from a single domain, which is also what HubSpot's iframe modal requires for secure cross-frame messaging.
GDPR
You are the controller of the personal data in your HubSpot portal. Rehnable acts as a processor for the limited processing Rehnable performs on your instruction — which, because nothing is stored, is essentially "read on demand and write what the user asked for".
Our infrastructure runs in the EU (Sweden Central). Where your HubSpot data is hosted is determined by your own HubSpot account, not by us.
Erasure, access and portability requests are answered inside HubSpot, because that is where the data lives. There is no second copy in our system to find and delete.
A data processing agreement is available on request, listing Microsoft Azure (EU hosting) and Stripe (billing) as subprocessors. Ask and we will send it.
CRM data: none, so nothing to retain. Portal configuration is kept while you are installed; the refresh token is deleted when the installation is marked as removed, within about half an hour of you uninstalling.
We do not currently hold ISO 27001 or SOC 2 — we would rather say so than imply otherwise. What we can offer is an architecture where the sensitive data never arrives, and a straight answer to any security question you send.
Write integrity
Every structural change is checked server-side before a single API call goes out — a move that would create a reporting loop is refused even if the client somehow allowed it.
Some changes need two HubSpot calls. When the second one fails, Rehnable either reverses the first or surfaces a clear error. It never leaves your CRM quietly inconsistent.
A batch operation where some rows fail is reported as a failure with the details, not as a success with silently missing records.
Requests are batched, chunked and throttled to stay within your portal's HubSpot limits, with backoff and retry on the limits that do get hit — Rehnable should never be the reason another integration starts failing.
Bulk actions have hard caps enforced on the server as well as in the UI, so one oversized selection cannot turn into a runaway job against your portal.
Structural writes are undoable from the editor, and every change is an ordinary HubSpot association or property value that an admin can inspect and fix directly.
Offboarding
The test of a data promise is what remains after you stop paying. Here is the honest answer.
| On uninstall | What happens |
|---|---|
| Access to your portal | Your authorisation is revoked at once. HubSpot invalidates the long-lived credential but not access tokens it has already issued, so a credential we hold can remain valid for up to about 30 minutes — after which our first failed renewal marks the installation as removed and every path is closed. We are shortening that window; we would rather document it than round it to "immediate" |
| Your refresh token | Deleted from our database |
| Reporting lines | Stay in your portal as ordinary contact associations |
| Team values | Stay on your contacts as an ordinary property |
| Lists and tasks you created | Stay in HubSpot, exactly like anything else you created there |
| Portal configuration on our side | Retained so a reinstall picks up where you left off — deleted on request |
You can also delete the association labels and the orgchart_team property
yourself from HubSpot's settings if you want no trace of the app left behind. That is
your call to make, not ours.
Found something? Email hello@rehnable.com with the details. We will confirm receipt, work the issue, and tell you what we did.
The terms of service and the privacy policy are published, and the privacy policy contains the GDPR Article 28 processing terms in full. A separate signable data processing agreement with the same content is available on request.
Send them. Vague reassurance is worse than a specific "not yet", and you will get the specific answer.