Security is what the system enforces.
Your reviewer needs more than a promise that data is safe.
Workloom puts controls at the points where outbound work can cause damage. Credentials are encrypted and kept out of logs. Permissions are checked on every request. Consequential actions are recorded. AI actions wait for consent, guardrails and approval. Some statements describe enforced controls. Others describe what Workloom does not claim. The distinction matters.
What we hold
The useful question is not whether a system stores data. It is what it stores, how it protects access, and when it removes records.
Workloom holds the data needed to run your outbound workflows, including the lead data you upload and the credentials or connection tokens used to connect your accounts. Stored credentials and connection tokens are encrypted with AES-256-GCM. They are never written to logs. They are never returned by an API read. That blocks two common escape routes: secrets appearing in operational records and secrets being exposed through an ordinary read request.
Retention is tied to the job that created the record. Verification results stay fresh for 30 days, then are deleted at 90 days. Signal jobs clear after 7 days. Those are system rules, not guidance for an operator to remember later. If your team needs a result after its retention window, keep the permitted record in your own systems rather than assuming Workloom will preserve it indefinitely.
You keep ownership of everything you upload. Workloom claims no ownership of customer lead data and does not sell or rent personal data. That statement covers ownership and commercial use. It does not mean every record remains forever, or that every teammate can see every upload. Access and retention still follow the controls described here. The operating entity is Zaurion Ventures LLP, registered in Pune, Maharashtra, India. See the privacy policy for the governing detail.
Who can see what
Access is scoped to the organization, seat and user, then checked again when a request reaches the system.
Workloom uses an organization, seat and user model with 16 distinct permission flags. The checks run on every request, not only in the interface. That matters when someone bypasses a screen, calls an endpoint directly, or uses an action surfaced by another part of the product. The interface can hide an option, but the request check is what decides whether the action is allowed.
A teammate can be hard-partitioned as a scoped operator. That operator sees only the mailboxes, campaigns, lists and prospects assigned to their seat. The boundary is enforced in the query layer, where records are selected, rather than painted over in the UI after broader data has already been fetched. If a seat should handle one mailbox and one campaign, assign that scope deliberately and review the permission flags around it.
This is where many outbound systems fail quietly. A role looks restricted until a report, export, or background action crosses the boundary. Workloom applies the access model to requests across the product, so the review should focus on assignments and permissions, not screenshots of menus. For the broader system shape, see infrastructure and platform. Those pages explain the operating model without pretending that a diagram is itself a control.
What is written down
If an action can change outbound behavior, the system records it in an append-only audit trail.
Consequential actions are written to append-only audit logs across mail, campaigns, messaging and warmup. Append-only means the record is built for addition, not silent editing after the fact. The logs are retained for 90 days. That gives a reviewer a defined window to inspect what happened after a mailbox changed, a campaign moved, a message was sent, or warmup behavior was altered.
AI actions have a separate control path before anything leaves the system. Every action passes consent checks, guardrails and an approval queue. The point is not to claim that generated work is automatically safe. The point is to stop an action at the boundary where it could become an external message or other outbound activity. If approval is required, the action waits. It does not quietly pass through because a model produced it.
Outbound integrations also have rate limiting and circuit breakers in front of every connection. A failing provider is therefore contained rather than allowed to cascade through the rest of the workflow. These controls address traffic and failure behavior, not business judgment. Your team still decides what should be sent, which accounts should connect, and who may approve an action. The logs and approval queue give your reviewer something concrete to inspect when those decisions are questioned.
What we do not claim
A clear security review separates an enforced mechanism from a statement about intent, ownership or future operation.
We claim specific controls, not an abstract guarantee that nothing can ever go wrong. Encryption protects stored credentials and connection tokens. Request-level permissions restrict access. Query-layer partitioning limits what a scoped operator can see. Audit logs preserve consequential records for 90 days. These are controls with defined locations and behavior. They are different from saying a system is simply secure because a page says so.
We do not claim ownership of your uploaded lead data, and we do not sell or rent personal data. We also do not claim that retention is unlimited. Verification results expire, verification records are deleted at 90 days, and signal jobs clear after 7 days. We do not claim that a UI role alone protects data, because the enforcement point is the request and query layers. Review your own retention needs and preserve permitted records on your side when required.
We do not claim that consent, approval or a do-not-call rule can replace sound operating practice. Do-not-call is enforced as a hard block on every dial path, not as a filter applied only when a list is built. Rate limits and circuit breakers contain integration failures, but they do not decide whether a campaign belongs in your market. For legal terms, data handling and the limits of each commitment, use the privacy policy rather than treating this page as a contract.
What operators ask first
Are connection credentials returned through the API?
No. Stored credentials and connection tokens are encrypted with AES-256-GCM, never written to logs and never returned by an API read.
Can a scoped operator see another seat's prospects?
Not when the seat is hard-partitioned. The operator sees only the mailboxes, campaigns, lists and prospects assigned to that seat, with the boundary enforced in the query layer.
How long are audit records retained?
Consequential actions across mail, campaigns, messaging and warmup are written to append-only audit logs retained for 90 days.
Can a do-not-call prospect still reach a dial path?
Do-not-call is a hard block on every dial path. It is not only a filter applied while building a list.
Bring your reviewer the mechanism
Use the controls above to map Workloom to your access, retention and outbound review requirements.