Security

Controls that behave the way finance expects.

Security is part of how PulseControl is structured: who can see what, what is recorded, and what operators can observe. This page describes that design and is explicit about what it does not claim.

Request security documentation What we do and do not claim

This page describes the intended design of the platform. It is not a certification, attestation or audit statement.

01 · Security approach

Four principles, applied throughout.

Least privilege

Users, API keys and integrations receive only the access their job needs, and nothing more by default.

Separation

Each workspace is kept apart from every other, and sources are isolated from one another within a workspace.

Record every change

Anything that changes state, human or API, is written to an append-only audit trail with actor and time.

Show operators the truth

Connection health, delay and failure are shown in the product, not hidden behind a status page.

02 · Data protection

Encrypted, scoped and handled as secrets.

Financial data is encrypted in transit and at rest. Credentials for connected systems are stored and used as secrets, and are never displayed back in the interface.

Data protection design
Area	Design
In transit	Connections to the product, to the API and to connected sources use encrypted transport.
At rest	Stored data is encrypted. Original payloads are retained by reference for traceability.
Credentials	Source credentials are stored as secrets, scoped to read what is needed, and masked after entry.
Isolation	Workspaces are logically separated, with access checks on every read and write.

03 · Access control

Roles that match how finance teams work.

Permissions are granted by role and by connected source, so a team can see its own sources and approve its own variances.

Illustrative role permissions
Permission	Viewer	Analyst	Approver
View reconciliation and exceptions
Investigate and add notes	—
Resolve exceptions	—
Approve variances above a threshold	—	—
Manage sources and credentials	—	—	—
Manage users and roles	—	—	—

04 · Auditability

Every action stays reviewable.

Audit entries record who did what, when, and what changed. They are appended, not edited.

Audit entryillustrative

{
  "id": "aud_01HZX48555",
  "time": "2026-10-06T09:36:02+05:30",
  "actor": "demo.analyst",
  "action": "exception.resolved",
  "object": "PX-48291",
  "before": { "status": "investigating" },
  "after": { "status": "resolved", "reason": "Provider hold released" }
}

Human and API actions are recorded the same way.
Entries include before and after state for every change.
Reviewers can reconstruct a case from its entries alone.

05 · Infrastructure monitoring

Health that operators can see.

Source health states
State	Meaning	What operators see
Operational	Events are arriving within the expected cadence.	Last event time and counts
Delayed	A source has fallen behind its expected cadence.	Delay duration, affected reconciliations
Failed	A connection or delivery is failing.	Error class, retry state, affected scope

06 · API security

Scoped keys, signed events, safe retries.

API access is authenticated and limited to what each key needs. Webhooks are signed, and writes accept idempotency keys.

Scoped keys

Keys belong to one workspace and carry only the permissions they need. Read-only keys cannot change state.

Signed webhooks

Each delivery carries a signature the receiver can verify before trusting the payload.

Rate limits and idempotency

Requests are rate limited, and retried writes with the same key cannot create duplicates.

07 · Enterprise controls

Policy controls for larger teams.

Larger organizations need to apply their own access policy. These controls are planned and described here for transparency.

Single sign-on

Planned

Policy controls

Planned

Organization-wide rules for who may approve, resolve and administer, applied across workspaces.

Arrangements by agreement

Requirements such as data handling, review rights and support terms are scoped with Enterprise customers.

ControlBehaviorWhere you see it

Enterprise access controlsPlannedSingle sign-on and policy controls for larger teams.Settings · Policies

08 · Status

What we do and do not claim.

A new platform should be precise about what has been independently verified.

Claims and non-claims
Topic	Position
Compliance certifications	None are claimed. SOC 2, ISO 27001, PCI DSS and GDPR certification are not stated or implied.
Independent audits	None are claimed on this site. Any future audit will be stated plainly, with scope and date.
Customer data	This website shows synthetic data only. No real customer, account or payment data is displayed.
Documentation	Security documentation and architecture reviews are available on request.

Questions about security?

Ask us for documentation or an architecture review. We will answer plainly, including where something is not yet in place.

Talk to us Explore the platform