Trust

Trust & Security

Effective date: 11 October 2026

Trust center

What is in place, what is in progress, and what you can ask us for. Open a card for the detail. A row is marked in place only after it has been checked against production.

  • In place 33
  • In progress 1
  • On request 6

Governance and policies

The rules PulseAI holds itself to, who approved them, and where it falls short of them.

  • Security policy set

    In place

    Eleven approved policies cover information security, access control, data handling, change management, vulnerability management, incident response, continuity, risk, vendors, conduct, and acceptable use. Each is versioned, pinned to an integrity hash, and reviewed at least once a year.

  • Artificial Intelligence Policy

    In place

    Our own AI policy governs how we build AI into the product and how we use AI tools ourselves. It is the policy we would ask a customer to have.

  • Exceptions stated in writing

    In place

    Where we do not yet meet one of our own policies, the policy says so, names what stands in its place, and carries a review date. We would rather show you the gap than have you find it.

  • Risk register

    In place

    A risk register is maintained under an approved method: each risk is rated with and without its controls, given an owner and a treatment, and tied to the control that addresses it. It is reviewed at least once a year and whenever the system changes materially.

  • Policies for your review

    On request

    Any policy in the set is available to customers and prospects under a confidentiality agreement.

    security@pulseai.now

Product security

How your people sign in and what keeps one organization out of another’s workspace.

  • Tenant isolation

    In place

    Every request is scoped to the organization in the verified sign-in token. One customer’s data cannot be read from another customer’s workspace.

  • Role-based access

    In place

    Four roles, checked on every request. A read-only user is limited at the gateway, not only in the interface.

  • Multi-factor authentication

    In place

    Required for every password account. When you sign in through your own identity provider, your provider enforces it.

  • Single sign-on

    In place

    SAML 2.0 federation with your identity provider. You prove you own a domain through DNS before it can be used for sign-in.

  • Administrative audit trail

    In place

    User, role, identity provider, and policy changes in your workspace are recorded and visible to your administrators.

Data security

Where your data lives, how it is protected, and what happens to it when you leave.

  • Encryption

    In place

    TLS 1.2 or higher in transit and AES-256 at rest, with managed keys that cannot be exported.

  • Data residency

    In place

    Canada and the United States are live. All of your data is stored, and backed up, in the jurisdiction you choose. One exception: for customers in Canada, the text that AI features work on is processed by our model provider in the United States, until that processing is available in Canada. It is never used to train models.

  • Deletion

    In place

    We delete or return your data within 30 days of termination. Deletion follows a documented process that has been tested, and it leaves a record of what was removed. Encrypted backups are not altered and expire automatically within 90 days.

    Privacy Policy →

  • Backups

    In place

    Continuous point-in-time recovery covers the last 35 days. Scheduled daily and monthly backups, encrypted and kept in the same region, are in place in every production region. None is kept longer than 90 days.

  • No training on your data

    In place

    Your content is never used to train or fine-tune models, by PulseAI or by its vendors.

Evidence integrity

What the Evidence Vault guarantees, and how you check it without trusting us.

  • Write-once storage

    In place

    Governance records are sealed into write-once storage for the full term of your retention profile. No one, PulseAI included, can alter or delete them early.

  • A key that is yours alone

    In place

    Your evidence is encrypted under a key that belongs to your organization. Destroying that key when you leave is how your evidence is erased.

  • Verifiable offline

    In place

    Signed digests and evidence bundles verify with standard tools against the public keys published on this page.

    Verifying evidence bundles →

  • Legal hold

    In place

    A legal hold blocks erasure until it is released, and a release leaves a record.

Infrastructure

What the platform runs on and how its regions are kept apart.

  • Managed cloud services

    In place

    The platform runs entirely on managed AWS services across multiple availability zones. There are no servers for PulseAI to patch.

    Subprocessors →

  • Independent regions

    In place

    Each hosting region is its own isolated deployment. A failure or a security event in one region cannot reach another.

  • Infrastructure as code

    In place

    Every environment is defined in version-controlled code and changed through the deployment pipeline.

  • No public storage

    In place

    Storage is never publicly readable. Files reach your browser through short-lived signed links.

Application security

How code reaches production, what scans it on the way, and how weaknesses are handled.

  • Web application firewall

    In place

    All public web endpoints are protected by a web application firewall.

  • Tested and scanned changes

    In place

    Every change to the platform is a pull request that must pass its automated checks before it can merge: tests, static analysis, infrastructure policy scanning, a dependency audit, and secret scanning. The rule applies to administrators too. Releases to staging and production wait for an explicit approval. PulseAI is founder-led, so changes are tested and scanned, not independently reviewed.

  • Weekly dynamic scan

    In place

    The application is scanned from the outside every week.

  • Vulnerability disclosure

    In place

    A public coordinated disclosure policy with safe harbor for good-faith research. Reports are acknowledged within 3 business days.

    Security disclosure policy →

  • Software bill of materials

    On request

    Produced for every release, for the backend and the frontend.

    security@pulseai.now

Monitoring and response

What is recorded, what raises an alarm, and what you hear from us when something goes wrong.

  • Public status page

    In place

    Service incidents and scheduled maintenance are published on a status page hosted separately from the platform it reports on.

    status.pulseai.now →

  • Audit logging

    In place

    Administrative activity across all production accounts is logged to storage that cannot be quietly altered.

  • Security alerting

    In place

    Detective alarms watch for privileged sign-ins, access and policy changes, and attempts to disable encryption keys.

  • Incident response plan

    In place

    A written plan sets severities, roles, and notification duties. A confirmed breach of your data is notified to you within 72 hours.

Privacy and compliance

The privacy laws we align to, and how we handle your data under them.

  • PIPEDA-aligned

    In place

    Processing follows Canada’s federal privacy law, with a data minimization commitment and data subject requests answered within 30 days.

    Privacy Policy →

  • Published subprocessors

    In place

    Every third party that touches customer data is listed with its purpose, and you get 30 days’ notice before one is added.

    Subprocessors →

  • No tracking on this website

    In place

    No analytics scripts and no tracking pixels. Visits are counted only in aggregate from our own server logs.

    Cookies →

  • GDPR

    In progress

    Data subject rights workflows operate today. Standard Contractual Clauses and the UK addendum are added to the agreement when European Union hosting ships.

Documents and self-assessments

What your security team can ask for. Each is shared under a confidentiality agreement.

  • Security package

    On request

    The full control catalog, with the status of every control, shared under a confidentiality agreement.

    security@pulseai.now

  • Data Processing Agreement

    On request

    A standard agreement covering processor obligations, sub-processing, breach notification, and return or deletion at the end of the contract, shared under a confidentiality agreement.

    legal@pulseai.now

  • Your security questionnaire

    On request

    Send us your own template and we will complete it from the control catalog. Our answers are shared under a confidentiality agreement.

    security@pulseai.now

  • CAIQ self-assessment

    On request

    A completed Cloud Security Alliance CAIQ v4.1 self-assessment: 283 questions, answered Yes, No, or Not Applicable, with who is responsible for each control. It says No where a control is not in place. Shared under a confidentiality agreement.

    security@pulseai.now

Privacy by minimization

PulseAI runs no analytics scripts on this website and counts visits only in aggregate from its own server logs. It does not use tracking pixels, does not sell or share personal data, and does not use customer data to train third-party AI models. The only cookies we set are the ones required to keep you signed in to the product application and protect against CSRF.

How we handle cookies → /cookies · Privacy Policy → /legal/privacy

Security posture

  • Hosting: Canada and the United States live today; European Union hosting is available on request.
  • Encryption: TLS 1.2+ in transit; AES-256 at rest via managed key-management.
  • Identity: Managed identity provider with MFA required for all users; least-privilege access control across the platform.
  • Audit: Comprehensive audit logging enabled across all production accounts; logs retained per our audit-storage policy.
  • Network: All public web endpoints are protected by a web application firewall.
  • Availability: Service incidents and scheduled maintenance are published at status.pulseai.now.

Compliance

  • PIPEDA-aligned (Canada). Privacy Policy at /legal/privacy.
  • GDPR-ready. All data-subject-rights workflows operational; SCCs and UK IDTA appendix will be added when the EU deployment ships.
  • EU CRA vulnerability-handling commitments active. See /security.
  • No attestation claims. PulseAI does not claim attestation against ISO 42001, the EU AI Act, or Canada's Directive on Automated Decision-Making. See /audit-ready for our governance approach to producing audit-ready evidence.

Verifying evidence bundles

PulseAI's Evidence Vault seals five kinds of governance record into write-once storage as they happen: an attestation certified, an AI Impact Assessment approved, a shadow-AI application resolved, an AI policy activated, and the weekly health report. Your administrators can cut any scope of those records into a signed evidence bundle to hand an auditor: a ZIP holding manifest.json, a detached signature manifest.sig, the raw stored bytes of every record under payloads/, and a summary PDF. Anyone holding the bundle can check it offline with standard tooling, against the public keys published on this page. No PulseAI account, no PulseAI software, no network access.

Signing keys

Each hosting jurisdiction is a separate deployment with its own signing key: ECDSA on curve NIST P-256, held in a managed key service whose private half has no export path. The public halves are published here. Accept a key from this page and from nowhere else, including from whoever handed you the bundle: anyone able to substitute the key can also hand you a chain it signs. Confirm the fingerprint before trusting a result, and record it in your own files at onboarding so a later substitution shows up as a mismatch rather than a surprise.

Hosted in Public key SHA-256 of the PEM file Active from
Canada evidence-signing-canada-2026-08-22.pem cea1cfc08e12642cc0a57c9f0a0e3cc08076f3b682a2f812fc328220ca398237 2026-08-22
United States evidence-signing-usa-2026-09-05.pem 20ef8aa3ad3791ea7227983378262f6fbff0d14c0aeb6d164703a0bd60f1c67a 2026-09-05
European Union Available on request from support@pulseai.now.

Each key file is named by the date it became active and is never replaced at that address: a rotation adds a new row and a new file, and the retired key stays listed with its retirement date and stays downloadable. Signatures made under a retired key remain verifiable against it forever, because verification is a pure function of the bytes, the signature and the public key, and needs nothing from PulseAI. Evaluation environments use their own keys, supplied with the evaluation materials; they are not listed here.

evidence-signing-canada-2026-08-22.pem (Canada)

-----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEvOyRj7X9clnvfeBJjj+XsJPeJwUx rY/P2D/F840+d++LqIbzKXWtfuUyG2EW751M+ZKR3LEknkzXAUk35OILFA== -----END PUBLIC KEY-----

evidence-signing-usa-2026-09-05.pem (United States)

-----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEX//FMhKpZbx32MFHDqFJ/BLaxiqj RwLorhI/rhsvL2O8l6Ja2Ji85dqiuwIQlMQ9mdRSssUNXpvbpyEjgB2ukA== -----END PUBLIC KEY-----

Verify a bundle

Everything below runs from the unzipped bundle plus the key, in bash or zsh, with openssl, shasum, jq and the usual diff, sort and sed. The commands assume the bundle is unzipped into bundle/ and the key for your jurisdiction is saved as pulseai-evidence-signing.pem. Steps 2 and 3 are the cryptographic checks, and none of the steps needs any PulseAI software.

  1. Confirm the key. The hash must equal the fingerprint in the table above.

    shasum -a 256 pulseai-evidence-signing.pem

  2. Verify the signature. manifest.sig is a small JSON file whose signature field is the base64 of a DER-encoded ECDSA signature over SHA-256 of manifest.json's exact bytes. Decode it, then let openssl do the rest:

    jq -r .signature bundle/manifest.sig | base64 -d > manifest.sig.der openssl dgst -sha256 -verify pulseai-evidence-signing.pem -signature manifest.sig.der bundle/manifest.json

    Verified OK means PulseAI produced this manifest and it has not changed since. Verification failure means the manifest's bytes are not the bytes that were signed, the signature was replaced, or you hold the wrong key for this jurisdiction or key era.
  3. Re-hash the payloads. Each entry in the manifest's receipts carries a contentHash of the form sha256:<hex>. Hash each payload's raw bytes and compare; never re-serialize before hashing:

    jq -r '.receipts[] | "\(.contentHash[7:]) bundle/payloads/\(.evidenceId).json"' bundle/manifest.json | shasum -a 256 -c

    A payload that fails here while step 2 passed means the manifest is authentic and that file was altered after signing.
  4. Check the set is exact. recordCount must equal the number of receipts, and payloads/ must hold exactly the files the manifest names. A file no receipt names sits outside everything the signature covers; treat it as a finding, not a packaging quirk:

    jq '.recordCount == (.receipts | length)' bundle/manifest.json diff <(jq -r '.receipts[].evidenceId' bundle/manifest.json | sort) <(ls bundle/payloads | sed 's/\.json$//' | sort)

  5. Tie it to the sealed chain (optional). The manifest's digestChain names the weekly digest links that cover its records. Ask PulseAI for those digest files and their signature sidecars, verify each against the same key with the step 2 procedure, and confirm the link covering the manifest's cutAt carries a bundleReceipts entry whose exportId matches the manifest's and whose sha256 (after its sha256: prefix) equals shasum -a 256 of the ZIP itself. This is what turns "PulseAI signed this manifest" into "PulseAI sealed this disclosure into a signed weekly chain, where any later change to the record shows up as a link that disagrees with its predecessor".

What the checks prove, and what they do not

  • The signature proves authenticity: PulseAI produced this manifest, and it has not been altered since.
  • Re-hashing proves internal consistency: the payload files are the ones the manifest names.
  • Neither proves completeness. The manifest's scope block states the filters the bundle was cut with, and its unsealedCount states how many records no weekly digest link has sealed yet. A non-zero count is normal for a bundle cut mid-week, not a defect; request a bundle cut after the next weekly seal if you need chain coverage for those records.
  • The summary PDF is a rendering, not evidence. It is not hashed by the manifest and is not checked by any verifier. Read it for orientation, never as an assertion.
  • The chain is fork-resistant, not fork-proof. PulseAI holds the signing authority, so PulseAI could in principle sign an alternative history from some point forward. Publishing digest roots to an independent external anchor, which would make even that detectable, is deferred work; we state the limit rather than imply it away.

This page is the complete customer procedure. PulseAI's Evidence Vault verification guide is the long form: it specifies the wire formats, covers the weekly digest chain in full, and ships a dependency-free verifier that performs steps 2 to 4 in one command. Both are available to customers and their auditors from support@pulseai.now, which is also where to report a verification failure. The openssl signature check and the per-record hash comparison are exercised against tampered and wrong-key fixtures in PulseAI's build on every change; the jq, shasum -c and diff lines above were run against a synthetic signed bundle, including the tampered-payload, extra-file and wrong-key cases, when this page was written.

Contact

Security disclosures
security@pulseai.now
Privacy questions
privacy@pulseai.now
Legal / DPA
legal@pulseai.now

PulseAI Now Inc. · Trust & Security · Version 1.5 · October 11, 2026