Understand how Truvoca handles data across your call workflow.
A meaningful security review starts with the exact call workflow, systems, data categories, artifacts, users, and regions involved. This page explains the questions Truvoca documents with a customer before deployment and separates verified controls from information still under review.
Truvoca does not use certification badges or broad compliance language without evidence. Architecture, vendors, locations, retention, encryption, access, and contractual documents must be approved by the responsible technical or legal owner before a specific public claim is added.
30 minutes over Google Meet. Times are shown in Eastern European Time (GMT+03:00). Scheduling runs on Google Calendar, so choosing a time takes you into Google’s service.
Start with the path, not a generic checklist
Map where data enters, moves, and leaves for the workflow.
The data flow should be documented for the specific deployment. A typical phone workflow may begin with a telephony event or an approved record, use Truvoca to process the conversation, exchange limited data with a connected system, create approved call artifacts, and route an exception to a person.
The diagram becomes authoritative only after every service, region, storage boundary, transfer, and system owner has been verified. Until then, it is a workflow model rather than an architecture claim.
- Telephony trigger or approved source record
- Agent processing under the workflow rules
- Read or write with the connected business system
- Approved logs, outcomes, recordings, transcripts, or summaries
- Human handoff, task, or notification when required
- Retention and deletion path for each data category
Collect only what the call needs
Define required data separately from optional call artifacts.
Each workflow should have a field-level inventory. Appointment confirmation, for example, may require an approved record identifier, permitted contact details, appointment context, conversation outcome, and the next action. The exact fields depend on the connected system and the customer's rules.
Recordings, transcripts, summaries, free-text notes, and analytics fields are separate data categories. They should not be enabled or retained by default in website copy; their purpose, access, and lifecycle must be documented first.
- Caller or recipient data required for the approved purpose
- Appointment, booking, lead, service, or support context
- Conversation rules and permitted reference information
- Outcome, disposition, action, and exception fields
- Optional recording, transcript, summary, and free-text artifacts
- Technical logs needed for operation, support, or security
Access follows the job being performed
Verify roles, permissions, credentials, and audit visibility.
A security review should document who can access customer data, which Truvoca personnel may need operational access, how customer and service identities authenticate, where credentials are handled, and what audit information is available.
The principle is to grant only the access required for the scoped workflow. The public page should name a control only after its implementation, enforcement, ownership, and exceptions have been verified.
- Customer roles and administrative access
- Truvoca operational and support access
- User and service authentication methods
- Integration credentials and secret handling
- Permissions for reads, writes, exports, and call artifacts
- Audit events visible to approved reviewers
- Access review and removal process
The lifecycle must be explicit
Document where each data category is stored and when it is removed.
Storage and retention cannot be summarized with one number. Source records, outcomes, logs, recordings, transcripts, summaries, backups, and support exports may follow different rules.
Before publication or deployment, Truvoca and the customer should confirm the services and regions involved, default and configurable retention, deletion requests, backup behavior, legal or operational exceptions, and how completion is verified. No location or retention period is stated publicly until that review is complete.
- Service and storage location
- Default and configurable retention by data category
- Customer deletion and account-closure workflow
- Backup scope and expiration
- Legal, security, billing, or incident exceptions
- Evidence that deletion or anonymization completed
Know which providers support the workflow
Maintain a dated inventory of vendors and subprocessors.
A useful subprocessor inventory names the provider, its purpose, the data categories involved, the service location or transfer context where known, and the process for notifying customers about material changes.
Only providers confirmed by architecture and contract review should appear. A telephony, model, hosting, analytics, scheduling, email, or support vendor should not be inferred from a logo, old configuration, or generic technology description.
- Provider and service
- Purpose in the Truvoca workflow
- Data categories processed
- Region or transfer context when verified
- Contract and security review owner
- Last-reviewed date
- Customer update mechanism
Recordings and transcripts are separate decisions
Configure call artifacts around purpose, notice, access, and retention.
A call can produce audio, a transcript, a summary, an outcome, structured action fields, and technical logs. Each artifact needs a defined purpose and owner. Recording or transcription also depends on the approved workflow, applicable notice or consent rules, customer instructions, and tested technical behavior.
If recording is disabled, the workflow should state which non-audio outcomes or logs remain. Redaction, download, export, deletion, and access claims appear only when the exact feature and control have been verified.
- Whether recording or transcription is enabled
- Required notice, consent, and calling rules
- Who can play, read, search, download, or export
- Purpose and retention for each artifact
- Redaction or masking only if implemented and tested
- Behavior when recording is disabled
- Deletion and exception handling
Plan for failures as well as successful calls
Define escalation, recovery, and customer communication before launch.
Operational trust includes what happens when telephony, agent processing, an integration, or a human route is unavailable. The deployment should identify failure signals, the person or team responsible, safe stop or no-write behavior, reconciliation, recovery tests, and the route for customer communication.
Incident response times, uptime commitments, recovery objectives, notification windows, and support channels are contractual or operational facts. They are not published until the process and evidence exist.
- Failure detection and ownership
- Safe stop, retry, or no-write behavior
- Duplicate protection and reconciliation
- Operational escalation and recovery testing
- Customer communication route
- Post-incident review and corrective actions
Evidence before badges
Ask for the current status of the requirement that matters to you.
Truvoca does not currently publish claims of SOC 2 certification, ISO 27001 certification, HIPAA compliance, BAA availability, PCI compliance, GDPR compliance, fixed data residency, or universal encryption coverage in this reference copy.
That statement does not determine whether a requirement can be supported. It means the public website will not imply readiness until the exact scope, evidence, agreement, and responsible owner have been confirmed. Reviewers should request the current factual status for their workflow.
- SOC 2Public claim not verified
- ISO 27001Public claim not verified
- HIPAA and BAAPublic claim and agreement availability not verified
- PCIPublic claim not verified; payment-data scope should be avoided unless explicitly designed
- GDPR and regional privacy requirementsEvaluate for the actual roles, data flow, regions, and contracts
- Encryption, residency, penetration testing, and vulnerability managementPublish only from approved technical evidence
Security depends on the complete workflow
Truvoca and the customer each control part of the deployment.
Truvoca can configure the product and connection around an approved scope. The customer remains responsible for the legitimacy of the calling purpose and recipient list, the information supplied, user access, business rules, retention choices, escalation destinations, and the legal or regulatory review required for its use.
Responsibilities should be written into the implementation plan and relevant agreements. This page explains the operating model; it does not provide legal advice or a compliance guarantee.
- CustomerCalling purpose, lawful basis or consent, recipient list, and timing rules
- CustomerData supplied, system permissions, users, and business policies
- SharedWorkflow scope, call disclosures, artifacts, retention, tests, and escalation
- TruvocaImplemented product configuration and documented connection behavior
- SharedMonitoring, incident coordination, changes, and periodic review
Review security in the context of the workflow you plan to deploy.
Tell us the use case, systems, data categories, expected regions, call artifacts, retention needs, contractual requirements, and the role of the reviewer. We will identify which facts are already documented, which require technical or legal confirmation, and what can be shared through an approved route.
Do not submit customer records, patient information, credentials, security reports, or confidential attachments through the public form.
FAQ
FAQ
What call data does Truvoca process?
The data depends on the approved workflow and connected systems. We document the minimum caller or recipient fields, business context, conversation inputs, outcome and action fields, technical logs, and any optional recordings, transcripts, or summaries separately.
Are calls recorded or transcribed?
Recording and transcription are configuration and workflow decisions. They depend on customer instructions, notice or consent rules, technical support, access, purpose, retention, and deletion behavior. This page does not present them as universally enabled.
Where is data stored?
The public reference copy does not name storage services or regions until the architecture and deployment scope are verified. A security review should identify the services, locations, transfers, backups, and owners for every relevant data category.
How long is data retained?
No universal retention period is stated in this draft. Retention must be verified by data category, including outcomes, logs, recordings, transcripts, summaries, backups, exports, deletion requests, and approved exceptions.
Who can access customer data?
Access should be documented by role for customer users, Truvoca operations and support, and service identities. Authentication, permissions, credential handling, audit visibility, reviews, and removal need implementation evidence before a specific control is claimed.
Which subprocessors are used?
A public list should be generated from the current architecture and contract inventory, with provider, purpose, data category, region or transfer context, last-reviewed date, and update process. That inventory is still an open proof requirement.
Is Truvoca HIPAA compliant or SOC 2 certified?
This reference copy makes neither claim. The current status, evidence scope, agreement availability, and workflow fit must be confirmed by the responsible technical and legal owners before any public statement.
Can we request a DPA or security review?
You can submit the requirement and reviewer role without attaching confidential material. Truvoca should confirm which documents and review process are currently available, then provide an approved exchange route where needed.