Keep access to customer data
under control
through explicit permission boundaries.
Pika Security & Privacy helps govern how customer data becomes accessible inside the platform through role-based access control, masked data views, API access control and shared responsibility boundaries.
The objective is not to publish unverified certifications or “complete security” claims, but to explain the technical access and data-exposure controls that can be verified in Pika.
What is Pika Security & Privacy?
Security & Privacy is Pika's security and data-privacy layer for helping control which platform areas and customer data users can access under their authorization context.
Core mechanisms include role-based access control, masked presentation of sensitive communication data where applicable and restricting API access through authentication context.
Security & Privacy answers one central question:
“Who can access which data under which permission?”
Security & Privacy is not the analytical layer that calculates customer behavior, it is not Consent Management for communication permission and it does not independently guarantee legal compliance.
Security is not a single badge or certification. It is controlled management of access and data exposure.
Explain trust through verifiable technical controls.
Generic terms such as “secure,” “enterprise” or “compliant” do not by themselves explain how a platform is protected.
Pika Security & Privacy therefore bases its security narrative on control mechanisms that can be verified.
Role-Based Access Control
User access inside the platform is constrained through authorization context.
Masked Data View
Masked presentation can be used in relevant interfaces to reduce unnecessary exposure of sensitive communication data.
API Access Control
Documented ingestion API access is protected through API-key based authentication context.
Consent & Delivery Controls
Consent Management and delivery-safety controls separately evaluate whether communication can be executed.
Verified control: CAN BE MARKETED.
Unverified certification: IS NOT MARKETED.
In security communication, mechanism comes before adjective.
Do not give every user the same access.
Pika uses role-based access control (RBAC).
RBAC allows platform areas and operations available to a user to be constrained according to their authorization context.
This avoids treating every authenticated user as if they have the same administrative or data-access permissions.
Authentication asks: "Who is the user?"
Authorization asks: "What can this user do?"
RBAC: helps manage authorization through role and permission context.
C14 does not claim fixed role names or an identical permission matrix in every deployment.
Access is determined not only by being authenticated, but by authorization context.
Access to data does not have to mean every field is shown in full.
Pika's security approach is not limited to whether a user can open a screen.
Masked data presentation can be used in relevant interfaces to reduce unnecessary full exposure of sensitive communication data.
A masked view does not mean the source data was deleted or that it never exists anywhere in the platform workflow.
Access control: manages whether a user can access an area.
Masked view: reduces unnecessary exposure of sensitive information inside an accessible area.
Authorization and visibility are different layers of the same security problem.
Do not leave programmatic data intake without authentication.
Pika's documented REST Ingestion API uses API-key based access for programmatic data ingestion.
X-API-Key: The API key is a technical control that allows a source to access the ingestion endpoint under authentication context.
This mechanism does not replace the data contract or validation processes owned by the Integrations layer.
API authentication asks: “Does this request come from an authorized access context?”
Data validation asks: “Does the payload match the expected data contract?”
They are: different controls.
API access security is the access layer of the data-ingestion process.
Do not turn tenant context into a claim of “a separate physical database for every customer.”
In a multi-customer SaaS platform, Pika treats user access through the relevant authorization and tenant context rather than authentication alone.
C14's security narrative focuses on constraining application access to the appropriate organization and authorization context.
This does not mean every customer has a physically separate database, server or isolated network.
The correct public boundary is: authorization / tenant context.
The unverified claim is: dedicated database or physical tenant isolation.
Do not expand a logical access boundary into an unverified infrastructure-topology claim.
Platform access and customer communication permission are different controls.
Security & Privacy focuses on user access to platform areas and data.
Consent Management helps evaluate available consent, IYS and opt-out context before customer communication is executed.
A user having permission to access Campaign Manager does not mean communication can be sent to any customer without consent controls.
Security & Privacy: “Which platform operations can this user access?”
Consent Management: “Can communication with this customer be executed under this consent context?”
User authorization and customer consent are separate control axes.
Separate AI preparation context from unnecessary direct personal identifiers.
Pika's documented AI-preparation architecture includes a data-minimization boundary intended to keep direct personal identifiers out of generative-AI prompt context.
The documented boundary includes excluding direct identifiers such as TCKN, raw phone numbers and full names from LLM prompt tokens.
This mechanism does not mean no personal data exists anywhere across Pika's systems or workflows.
The correct statement is: restrict direct identifiers inside AI prompt context.
The incorrect absolute claim is: “Pika is a Zero-PII platform.”
Do not turn the AI data boundary into an absolute claim that the entire product contains no personal data.
The platform provides controls. The organization manages its own access and data responsibilities.
Pika provides technical mechanisms such as access control, masked data views, API authentication and relevant delivery controls.
The organization continues to manage its own user accounts, who should have which access, the source of data brought into the platform and its own legal and operational policies.
Pika's Technical Control Area
- Platform access under role and permission context.
- Masked communication-data views in relevant interfaces.
- API-key access in documented API flows.
- Technical control mechanisms in consent and delivery layers.
The Organization's Control Area
- Correct assignment of user accounts and access permissions.
- The source and intended use of data brought into Pika.
- Internal data, security and access policies.
- Evaluation of applicable legal and operational obligations.
A technical security control does not replace organizational responsibility.
Do not present an unverified security claim as a product capability.
C14 builds trust through verified mechanisms rather than oversized adjectives.
No SOC 2 certification claim.
C14 does not market Pika as SOC 2 or SOC 2 Type II certified.
No SAML / SSO capability claim.
SAML, SAML 2.0 or Single Sign-On is not presented as a verified public security capability.
No specific at-rest encryption claim.
C14 does not guarantee AES-256 or another specific database-at-rest encryption standard.
No specific TLS version guarantee.
C14 makes no public guarantee for TLS 1.2+, TLS 1.3 or a particular cipher-suite level.
No physical tenant-isolation claim.
C14 does not claim a separate physical database, server or network segment for every customer.
No absolute security guarantee.
Technical controls help manage risk; no software feature represents a guarantee of zero security risk.
Instead of expanding what is unknown, we explain the controls we can verify.
Put Security & Privacy in the right place.
Security & Privacy is not Customer Intelligence.
Customer Intelligence calculates customer behavior and value context. Security & Privacy is concerned with the authorization context under which users can access those data and product areas.
Security & Privacy is not Consent Management.
Security & Privacy controls user access. Consent Management evaluates customer communication permission and suppression context.
Security & Privacy is not Integrations.
Integrations manages how data enters Pika. Security & Privacy explains security boundaries around programmatic and user access.
RBAC is not authentication itself.
Authentication establishes who the user is. RBAC helps constrain which operations the user is authorized to perform.
Masked data is not deleted data.
Masking reduces unnecessary full exposure in the user interface; it does not mean the data never exists in the system.
An API key does not replace data validation.
X-API-Key is part of access control. Payload validation and ingestion data contracts are separate mechanisms.
Security & Privacy is not a certification catalog.
Unverified SOC, ISO, SAML, encryption or infrastructure claims are not listed as security capabilities.
Security & Privacy is not a legal guarantee.
Pika provides technical controls; it does not guarantee that every legal and organizational obligation of the customer is automatically satisfied.
The role of Security & Privacy is not:
To say “we are completely secure.”
It is: To explain clearly and verifiably who can access which data under which control context.
Frequently Asked Questions
What is Pika Security & Privacy?
Does Pika use role-based access control?
Does Pika mask sensitive customer data?
How is access to the Pika Ingestion API controlled?
Does Pika use a separate physical database for every customer?
Is Pika SOC 2 or ISO 27001 certified?
Does Pika AI use no personal data at all?
What is the difference between Security & Privacy and Consent Management?
Constrain access.
Control data exposure.
Build trust through verified mechanisms.
Let's review how Pika's role-based access control, masked data views, API access control and shared responsibility boundaries apply within your platform usage context.
Pricing is tailored to your requirements and scope of use.