Security  /  Sovereign by construction

Bulletproof access control. Audited at every step.

Granular ACL. Mandatory 2FA for admin roles. Immutable audit trails with before-and-after values. AI operates under the same permissions as the user, never above.

600+ granular permissions Immutable audit log 2FA-gated reversals Permission-scoped AI Self-host or SaaS Audit-ready exports
The context

ISP security is different from enterprise IT.

ISPs handle a uniquely sensitive combination: customer personal information, financial records (billing and payment history), network credentials (OLT access, NAS secrets), and physical infrastructure locations. A breach doesn't just expose data, it can disable network access for thousands of customers, enable financial fraud, or reveal the physical location of critical infrastructure.

At the same time, ISP teams need to move fast. A support agent needs instant access to billing data. A NOC engineer needs to reboot an ONU remotely. A finance clerk needs to process payments and issue credit notes. Security that slows these workflows to a crawl gets bypassed, which is worse than no security at all.

ISPCQ's security model is designed for this exact tension: granular enough to protect sensitive operations, transparent enough that teams can work at full speed, and sovereign so the data stays where you decided it belongs.

Twelve years of building this for actual ISP operators (not as a checkbox feature for an enterprise compliance audit) shows in the details: every permission, every audit row, every reversal flow exists because somebody got it wrong in production once, and we made sure it could not happen again.

Governance

Three layers of access control.

ACL controls who can do what. Audit captures who did what. AI safety ensures Aelita can only do what the user can.

01
ACL v2 system
600+ permissions, dot-notation, role inheritance

600+ granular permissions organized into dot-notation paths that target specific modules, actions, and individual UI elements. A support agent can view customer billing statements but cannot issue credit notes. A finance clerk can process payments but cannot change contract plans. A NOC engineer can reboot ONUs but cannot modify billing rules. Each permission is explicit, inheritable through role hierarchies, and auditable.

  • Role inheritance via parent_role_id hierarchy
  • System, custom, and template role types
  • Permission Test tool for verifying access before deployment
  • Migration Preview for safe role restructuring
  • Performance monitoring so permission checks never slow operations
  • Context-aware rights (note-area visibility, IP-locked sensitive zones)
02
Immutable audit trail
Before / after / who / when / why

Every configuration change, permission check, and financial adjustment is logged with user ID, timestamp, IP address, and request context. Before-and-after values for every modification. Operators cannot edit or delete entries. When someone asks "who changed this customer's plan last Thursday?", the answer takes 10 seconds to find.

  • Immutable history; no tampering even by admins
  • Change-comparison views with before/after diffs
  • Filterable event history by user, action, module, date range
  • Audit-ready exports for regulators with full context
03
AI safety boundaries
Aelita inherits user ACL, never elevated

Aelita operates within the same strict permission scope as the logged-in user. If the user doesn't have permission to issue a credit note, Aelita can't do it either. All AI actions are draft-only by default; they require human review and explicit approval before taking effect. Speed of AI assistance without the risk of autonomous actions.

  • Scoped data access (no elevated privileges or backdoor)
  • Draft-only mode; nothing applied without explicit human approval
  • Human-in-the-loop reviews on every capability
  • Complete audit trail of AI context, draft, and human action
04
Note-level privacy & need-to-know visibility
Private DM notes, need-to-know mode, Confidential permission

Notes and tasks carry their own access controls. A private (DM) note is visible only to its officer and assignees — gated even against admins who hold view-all. A per-tenant need-to-know mode turns area-less categories from broadcast-to-all into see-only-if-you-belong, and a dedicated Confidential permission keeps management requests off agents’ screens.

05
Denied-access monitoring
Top Denied Permissions, granted-vs-denied breakdown

Beyond logging what changed, ISPCQ records every blocked permission attempt — who tried, from which IP, against which sensitive operation (deletes, payments, financial actions, role and permission edits). A live granted-vs-denied breakdown and a Top Denied Permissions panel surface the pattern at a glance, so a supervisor can spot someone probing operations they don’t have rights to before it becomes an incident.

  • Every denial captured with user, IP, and the operation attempted
  • Filter the audit log by result — Granted or Denied
  • Granted-vs-denied chart and a Top Denied Permissions ranking
06
Org-chart chain-of-command authority
Authority follows your live position in the org structure

Authority follows your live position in the org structure, not just a static role grant. A team leader, department manager, or division head can act on work raised by anyone beneath them in the hierarchy — close, reopen, approve, reject — checked by walking the active org-unit tree at the moment of the action. Authority updates the instant someone’s reporting line changes, with no permission to reassign by hand.

07
Tamper-proof role definitions
System and template roles are read-only; in-use roles can’t be deleted

The permission model protects itself. Built-in system and template roles are read-only and cannot be silently edited or deleted, and any role with staff currently assigned to it cannot be removed. A misclick or a malicious change can’t quietly strip or rewrite a live access policy.

Real-life scenario

Investigating a suspicious credit note at 11 PM.

The discovery. During a routine morning audit review, the finance supervisor notices an unusual pattern: a support agent issued 4 credit notes totalling €1,840 the previous evening, all to accounts in the same address cluster. The amounts are just below the supervisor approval threshold of €500 each.

The investigation. The supervisor opens the audit trail and sees every action: the agent searched for each customer by name, opened their billing page, created a manual credit note with a generic reason ("billing correction"), and applied it. The timestamps show the actions were rapid: 2 minutes between each. The supervisor checks the agent's login session: the IP address matches the office network, and the session was authenticated with 2FA.

The resolution. The supervisor freezes the agent's credit-note permission immediately through ACL v2 (without disrupting their other work), flags the 4 credit notes for review, and schedules a morning meeting with HR. The entire investigation, from alert to action, took 12 minutes. Without the audit trail and automated pattern detection, this might have continued for weeks before being noticed during month-end reconciliation.

Deployment security

Control where and how data lives.

ISPCQ security combines runtime controls with deployment sovereignty. Compliance and operations teams can meet policy requirements without slowing execution.

01
Sovereign by construction.
Self-host on your hardware, your data centre, under your firewall rules. Or run as ISPCQ-managed SaaS on dedicated isolated instances; you still own the data, you can export it at any time. Either way, your data stays under your governance, never silently shared with anyone else.
02
Operational safeguards on high-risk actions.
Certain operations are inherently high-risk: deleting a customer record, reversing a batch of payments, changing OLT credentials. These can be configured to require additional authentication steps, supervisor approval, or IP-restricted access. Configurable per action type; you decide what needs extra protection based on your risk profile. Portal accounts get the same rigour: verified email change — a customer changing their portal email must confirm via a link sent to the new address, with an anti-enumeration uniqueness guard and a single-use token, closing a cross-account takeover path. Brute-force throttling on login and 2FA (email- and IP-keyed lockout), CSRF protection on state-changing requests, and trusted-client-IP resolution that can’t be defeated by spoofed forwarding headers. A single visibility gate now guards every note read and write surface, after a module-wide sweep closed access-scope gaps.
03
Compliance reporting on demand.
When a regulator or auditor asks for activity records, export filtered audit trails by date range, user, action type, or module. The export includes full context: not just "user X changed record Y" but the before-and-after values, the reason provided, and the approval chain. A week-long audit preparation becomes a same-day response.