Snapshot 55044
Normalized text
Scripts and page chrome removed; this is what change detection compares.
Security & data The safest place for your CRM data is your CRM 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 Four rules the architecture is built on 1. No CRM data at rest 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. 2. Tokens never reach the browser 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. 3. OAuth only, minimal permissions 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. 4. Sessions come from HubSpot, not from a URL 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 Exactly what we store — and what we do not This is the complete list, not a summary. If something is not in the left column, it is not in our database. Contact details for the customer relationship — the name and email address of the person who installed Rehnable and of the person who bought the subscription — are kept in Rehnable's own CRM, not in this database. See section 2 of the privacy policy. Stored on our side 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 Installer's user ID The HubSpot user ID of the person who installed Rehnable Association type IDs The numeric IDs of the Manager / Direct report labels in your portal Portal settings Team colours, card property choices, old manager association choice 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 Never stored on our side 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 What Rehnable asks for at install, and why 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, reading the name and stage of open deals when you open the deal picker, and reading which contacts are linked to the deal you select. No amounts, close dates, forecasts, line items or any other deal field are ever read. 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 How a session actually starts Card requests a launch The app card on the company record calls our backend through HubSpot's own fetch mechanism, which signs the request. We verify the signature The backend validates HubSpot's signature before doing anything else. That is what establishes portal, user and record — not the URL. Short-lived launch token A single-use token, valid for under a minute and bound to that portal, user and record, is handed to the card. Editor exchanges it 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 Where it runs and who is involved 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 Data protection, stated plainly Roles 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". Data residency Our infrastructure runs in the EU (Sweden Central). Where your HubSpot data is hosted is determined by your own HubSpot account, not by us. Data subject requests 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. DPA and subprocessors A data processing agreement is available on request, listing Microsoft Azure (EU hosting) and Stripe (billing) as subprocessors. Ask and we will send it. Retention 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. Certifications 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 We are writing to your production CRM. We treat it that way. Validated before written 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. Compensating actions 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. Partial success is failure A batch operation where some rows fail is reported as a failure with the details, not as a success with silently missing records. Rate-limit aware 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. Bounded operations 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. Reversible by design 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 What happens if you leave 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. Reporting a vulnerability Found something? Email hello@rehnable.com with the details. We will confirm receipt, work the issue, and tell you what we did. Terms and privacy policy 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. Security questions we have not answered here? Send them. Vague reassurance is worse than a specific "not yet", and you will get the specific answer. Ask a security question Security FAQ