Data Security and Privacy in Pryseflow

Businesses rely on Pryseflow to manage important operational information.

That can include customer records, products, invoices, payments, inventory, contracts, staff access, marketplace activity and other company data.

Pryseflow uses a combination of access controls, company-level data separation, protected credentials and secure operational workflows to help keep that information appropriately restricted.

Security is not based on one setting. It is built into how users, companies, permissions and sensitive operations are handled across the platform.

1. Company-Scoped Data Access

Pryseflow is a multi-company platform.

Users may own or participate in more than one company, but business records are generally handled within the context of the active company.

The selected company determines areas such as:

• Records

• Settings

• Permissions

• Currency

• Dashboard information

• Operational data

Knowing a record URL or identifier does not automatically provide access to it.

Pryseflow applies company-scope and record-policy checks when protected information is requested.

2. Roles and Permissions

Company ownership and staff access are treated differently.

Owners have full authority within their companies, while staff members receive company-specific access through assigned roles and permissions.

Permission groups cover areas including:

• Sales

• Spend

• Customers and vendors

• Products

• Inventory

• POS

• Projects

• Marketplace

• Online store

• Reports

• Staff

• Settings

Pryseflow also includes controls designed to prevent a manager from granting privileges they are not authorised to administer.

This helps businesses give staff the access they need without automatically exposing the entire company environment.

3. Authentication and Account Protection

Pryseflow supports authentication mechanisms for its web and native environments.

These include supported combinations of:

• Email and password

• Google sign-in

• Apple sign-in on supported native clients

• Email verification

• Password reset

• Password confirmation for sensitive actions

• Login throttling

• Security-event recording

These controls help protect account access and sensitive account operations.

Users are still responsible for protecting their passwords, devices and account credentials.

4. Sensitive Payment and Provider Credentials

Some Pryseflow functions require businesses to configure external payment or service providers.

Sensitive provider credentials are not intended to be displayed back to users in full after storage.

For example, payment-provider secrets are encrypted when stored.

The wider platform also treats provider and banking secrets as protected information that should not appear in rendered pages or documentation screenshots.

5. Verified Payment and Transfer Workflows

Payment and transfer security is not based only on what appears in the browser.

Pryseflow verifies supported payment-provider and transfer outcomes before treating them as completed.

Payment, webhook and transfer workflows are also designed to support safe retries where appropriate.

This helps reduce problems such as:

• Duplicate operations

• False payment confirmation

• Repeated webhook processing

• Inconsistent transfer outcomes

6. Protected Documents and Public Links

Some Pryseflow documents can be shared through public or customer-facing links.

Access to these links is controlled so that a token for one company or document does not expose unrelated company data.

Private project, contract and media files also use controlled download or preview paths.

For example, invoice public views are scoped so a link belonging to one company cannot be used to access another company's invoice.

7. Contract Integrity

Pryseflow applies additional integrity controls to digital contract workflows.

Contract content is sanitised, and issued-contract evidence is protected through hashing.

This helps protect issued contract evidence from being treated like an ordinary editable draft after signing workflows have begun.

8. Public Forms and Abuse Protection

Public-facing forms create a different type of security risk because they can be accessed without normal authenticated company access.

Pryseflow uses protections such as:

• Rate limiting

• Anti-bot controls

• Scoped public tokens

• Permission-aware APIs

These controls help reduce automated abuse and unauthorised access attempts.

9. Secure Staff Access

Staff members should use their own authorised access rather than sharing credentials.

Pryseflow roles and permissions are designed to limit each staff member to the areas their responsibilities require.

Removing a staff member revokes their current company access while preserving historic attribution on documents and activity.

This means the business does not lose the operational history of who performed earlier work when a team member leaves.

10. Data Deletion and Retention

Account deletion is not treated as immediate erasure of every record.

Pryseflow's account-deletion process includes a grace period, while financial and audit records may remain subject to their own retention requirements.

This is important because certain records may need to remain available for:

• Financial history

• Audit purposes

• Disputes

• Fraud prevention

• Legal or regulatory requirements

Customers and vendors can also be soft-deleted and restored where supported.

Deletion should therefore not be described as an instant removal of every piece of historical business information.

11. Product Data Import and Export

Pryseflow does support catalogue import and export functionality.

Products can be imported using CSV or XLSX templates, and the platform can provide a bulk catalogue export.

However, the implementation reference does not confirm a general privacy-oriented export centre for customers, sales history and inventory subsets.

The Knowledge Base should therefore distinguish catalogue export from broader personal-data portability or account-export claims.

12. Security Settings

Pryseflow includes a security-settings page in the web application.

However, the implementation reference classifies this area as Limited.

The route and view exist, but each control should be verified against the currently deployed interface before being documented as an editable or persistent setting.

For that reason, Base articles should not currently instruct users to enable MFA, revoke API keys, review active sessions or manage integration permissions unless those specific controls have been confirmed in the live release.

13. Integrations and Third-Party Providers

Some Pryseflow services rely on external providers.

These may include payment, shipping, identity, mapping or other operational services.

Provider availability can depend on:

• Country

• Credentials

• Company configuration

• Provider verification

• Service availability

Sensitive provider credentials are protected, and normal platform permissions still apply when integrated services are used.

Using an integration does not give users broader access to company information than their existing permissions allow.

Common Questions

Is business data separated between companies?

Yes.

Most business records are company-scoped, and Pryseflow applies company and policy checks when protected records are accessed.

Can staff see everything in the company?

No.

Staff access depends on their assigned company roles and permissions. Owners retain full company authority.

Are payment credentials protected?

Yes.

Provider secrets are encrypted and are not returned in full after storage.

Does Pryseflow support MFA?

Pryseflow does not confirm a released MFA workflow.

The security settings page exists, but individual controls must be verified before they are documented as functional.

Can I review active sessions and API keys?

Pryseflow does not confirm merchant-facing session or API-key management screens.

Can I export all customer and sales data from a privacy dashboard?

Pryseflow confirms product catalogue export, but it does not establish a general privacy data-export dashboard.

Does Pryseflow automatically anonymise a customer when they ask to be deleted?

Pryseflow does not confirm an automated customer anonymisation workflow.

Does every Pryseflow store automatically receive a generated privacy policy?

Pryseflow does not confirm automatic storefront privacy-policy generation.

Businesses remain responsible for ensuring that the legal and privacy information they publish is appropriate for their operations.

Does Pryseflow use AES-256-GCM for every stored business record?

Pryseflow confirms encryption of sensitive secrets such as provider and banking credentials, but it does not establish that all business data is encrypted using that specific algorithm.

It is better not to publish a cryptographic specification that the implementation reference does not support.

Security Is Built Into the Operating Model

Pryseflow security is not one button or one dashboard.

It is built into how the platform controls:

Users → Companies → Permissions → Records → Credentials → Documents → Payments

That creates a more useful security story than promising controls that do not yet exist.

Pryseflow continues to protect business operations through scoped access, controlled permissions, protected credentials, verified transaction workflows and secure document handling.

Control access. Protect records. Operate with confidence on Pryseflow.