Security and architecture
What crosses the boundary, and what never does
You are going to read this before the call, so it is written to be read that way: specific enough to argue with, and honest about what we do not yet hold.
01 The agent
Collection runs inside your estate
The competitive shape of this market is SaaS-first: hand the vendor a privileged directory account, let their cloud reach into your estate. We do the opposite, and it is the single biggest architectural decision in the product.
-
01 / install
On a domain-joined host you own
A Windows service on a server inside your network, sized like any other management agent. You choose the host, you patch it, you own it. It is not a virtual appliance we ship you and it does not need its own subnet.
-
02 / authenticate
With a service account you create and hold
Read-only for discovery. Write permissions are granted separately, per scope, and only once you decide to let the platform make changes. The credential lives in the agent host's protected configuration and is never sent anywhere. You can rotate it, restrict it, or disable it without notifying us — and collection will stop, because it should.
-
03 / communicate
Outbound only, TCP 443, agent to platform
The agent initiates every connection. The platform never initiates a connection towards your estate and has nowhere to send one. There is no inbound firewall rule, no NAT entry, no VPN tunnel, no site-to-site link, and no listening port exposed at your perimeter. Traffic is TLS, and the destination is a fixed hostname your network team can allow specifically rather than a range.
-
04 / stop
Revocable from your side alone
Stop the service and collection stops. Disable the service account and collection stops whether or not the service is running. Block the outbound hostname and collection stops regardless of both. Three independent controls, all of them yours.
The consequence worth stating directly: there is no point in this design at which your directory credentials are transmitted to us, so there is no version of a breach at our end that discloses them. That is a property of the architecture rather than a promise about our operational practices.
02 The boundary
What stays on premises and what the platform holds
The honest summary: we hold the shape of your access, not the means to use it.
| Item | Held where | Detail |
|---|---|---|
| Directory service-account credentials | Your estate only | Created by you, held in the agent host configuration, never transmitted. |
| Password hashes | Your estate only | Never read by the agent. Not part of the collection scope. |
| File and mailbox contents | Your estate only | The platform records that a group grants access to a share. It does not open the share. |
| Kerberos tickets, secrets, certificates | Your estate only | Out of scope entirely. |
| Object names and distinguished names | Platform | Users, groups, containers and the resources access is granted over. |
| Group structure and membership | Platform | Including nesting, so effective access can be resolved. |
| Account state and lifecycle dates | Platform | Enabled or disabled, last sign-in, created and modified timestamps. |
| Approval records and change history | Platform | Approver, date, reason, before state, and the reversal if there was one. |
03 Data handling
Residency, isolation and retention
- Residency
- Platform data is processed and stored in EU regions. Backups stay in the EU. Support access is from the EU. If a sub-processor is ever added outside the EU you will be told before it happens, not in a changelog afterwards.
- Tenant isolation
- Each tenant's data is separated at the storage layer rather than by a tenant column filtered in application code. The distinction matters: a filter is one missing predicate away from a cross-tenant read, and that class of bug is the most common way multi-tenant platforms leak. Groups of tenants under one IT function can be linked deliberately, by you.
- Audit logging
- Every read, every change and every approval is recorded with actor, timestamp, before state and reason. Administrative actions by us are recorded in the same log you can read — there is no separate vendor log you cannot see. Logs are append-only and exportable, so your evidence does not depend on our continued existence.
- Revert
- Any change the platform made can be reversed from its own record, and the reversal is recorded as a change in its own right. Nothing is undone silently. An auditor can follow a grant, its approval, its removal and its restoration as four linked entries rather than four unrelated events.
- Retention and exit
- Retention is set per tenant and agreed before a trial rather than after. On termination your data is exported in a documented format and deleted within the period stated in the agreement. There is no lock-in through the file format.
- This website
- Static pages, no cookies, no third-party scripts, no fonts loaded from anyone else's CDN. Open the network tab: every request goes to this domain. A security vendor whose marketing site phones out to four analytics providers has told you something about the product.
04 Certification
Current certification status, stated plainly
You will verify these, so there is no version of this section worth overstating. Here is where we actually are.
-
In progress
ISO/IEC 27001
An information security management system is being implemented against the standard. The statement of applicability is drafted and controls are being evidenced. The certification audit has not taken place. We are not certified, and we will not describe ourselves as certified until a certificate exists with a number you can check.
-
Not held
SOC 2 Type II
No SOC 2 report exists. If your procurement process requires one before signature, we are not the right vendor this year and it is better that you know now.
-
In progress
External penetration test
A third-party test of the platform and the agent is scheduled. No completed report is available yet. Ask on the call and you will get the current position rather than a marketing answer.
-
Applicable
GDPR
We act as processor for the identity data described above. A data processing agreement, the current sub-processor list and the retention schedule are available on request, before any trial.
Why this page says all that
A vendor selling identity governance to a regulated operator while overstating its own certification position has demonstrated the exact failure the product is meant to prevent. If the honest answer costs us your shortlist, it was going to cost us the renewal anyway.
05 Verification
How to check any of this
Run the agent in a lab domain and watch it with your own tooling. Every claim on this page is observable from your side: put a packet capture on the agent host and confirm the direction and destination of traffic, audit the service account's effective rights, or pull the outbound hostname from the configuration and allow only that.
For the parts you cannot observe — residency, isolation, retention — ask for the data processing agreement, the sub-processor list and the architecture note before a trial, not after. They are written to be handed to your own auditor.
Security questions can go straight to hello@intense-systems.com without a sales call first. A completed vendor security questionnaire is not a prerequisite for a technical conversation, and neither is a purchase order.
Read it, then come and argue with it.
The technical call is with the person who made these architectural decisions, not with someone reading this page back to you.