Call recording spec: requirements for Verint, NICE and on-prem

Where problems usually start in call recording projects

Call recording and speech analytics are not bought to tick a box. Business needs them to resolve disputes with customers, improve agent performance, and find causes of losses. Security and compliance teams need them to investigate incidents, confirm facts, and reduce personal data risks.

Problems usually don't appear during the pilot but later, when the first real investigation or regulator request arrives. On demos everything looks simple: calls are recorded, search works, reports look neat. But once the system must be integrated into processes, you discover the requirements don't answer basic questions: who and how gets access, how long to keep recordings, what to do with sensitive fragments, and how to export materials so they can be used as evidence.

Details are often remembered too late:

• different retention rules by call type and deletion policies
• roles, action audit and separation of duties (who listens, who exports, who administers)
• masking and prohibition on listening to specific fragments (for example, card data)
• exports for investigations: format, integrity checks, chain-of-custody log

To keep requirements from growing uncontrollably and delaying the project, split them into two groups. Mandatory — those you must have to pass checks and perform safe investigations. Desirable — items that speed up work (for example, advanced analytics or extra dashboards) and can wait for phase two.

A simple rule: if a point affects security, access or the legal admissibility of a recording, it's nearly always a must-have.

Classes of solutions: Verint, NICE and on-prem, and what changes

Before writing requirements, it's useful to understand the class of solution. Broadly there are three groups: large platforms like Verint and NICE, specialized on-prem recorders (including SIPREC-capable devices), and hybrid schemes where some functions move to the cloud while storage stays on-prem.

The main difference between classes is not the UI buttons but which requirements become mandatory.

Cloud, on-prem and hybrid: how requirements differ

In cloud deployments you often hit legal and control questions: where data physically resides, how access is enforced, how exports for checks are handled. On-prem puts responsibility for resources and operation on you: disks, backups, updates, monitoring.

What to record up front:

• deployment model and boundaries of responsibility (who administers, who stores encryption keys)
• where speech analytics runs (in your environment or the vendor's) and what data is sent there
• scaling requirements: concurrent recording channels, storage growth, peak loads
• update plan and compatibility with your telephony and security policies

Where audio and metadata live

There are usually several layers: recording on the recorder or integration node, audio storage (files or object storage), a metadata database (who, when, where the call came from), and a separate index for search and analytics. The requirements should explicitly state which layers must be resilient and which data must be recoverable after failures.

Don't forget dependencies. In practice, projects stall not on recording itself but at integration points:

• telephony/contact-center (SIP, SIPREC, CTI, recording policy)
• CRM (customer card, call linking)
• SSO and roles (AD/LDAP, MFA)
• network zones and firewalls
• server infrastructure for on-prem (dedicated servers and disk shelves if you store recordings locally)

Describing these in advance makes it easier to agree on storage, access and exports without surprises.

Storage and retention: periods, encryption, backups, deletion

People often write storage in one line: "keep for 1 year." Later it turns out retention varies for sales, support and dispute cases, and some recordings must not be touched until a review finishes. Better to specify a retention matrix by call type, business unit, channel (inbound/outbound) and status (regular/incident/dispute).

Next — format and quality. State whether separate stereo channels are required (agent and customer separate), minimal sample rate/bitrate, and whether re-encoding is allowed when moving to archive. This affects storage size and speech recognition quality.

Split encryption into two layers: at-rest and in-transit. An often-missed point: who owns the keys and where they are stored (InfoSec, platform admin, separate HSM). In on-prem cases this is especially critical: without clear key ownership encryption becomes a formal requirement only.

Don't limit backups to the phrase "perform backups." Specify at least:

• RPO/RTO for the recording archive and for metadata
• what is backed up (audio, indexes, reference data, audit logs)
• backup frequency and retention of copies
• how often restore tests are performed and who signs the test report
• protection of backup copies (encryption, isolation, access control)

Deletion must be managed: automatic by schedule, deletion on request (for example, at the data subject's request), and deletion with confirmation. Require proof of deletion: an event in the log, object identifier, who initiated it, the justification, and what was deleted (audio, transcript, indexes). For investigations, define a "legal hold" mode so retention doesn't remove needed materials prematurely.

Access and control: roles, audit, separation of duties

If you don't define access rules, the call archive quickly becomes a shared dump with unclear actions. That's a risk for leaks and for internal disputes: one team will say "they won't let us work," another — "everyone can see everything."

Start with roles and boundaries. It's important not only who can listen but also who can export, delete, change recording rules and manage speech analytics dictionaries.

A minimal set of roles to specify:

• Agent: can listen only to their own calls (and only for the allowed period), no exports.
• Supervisor: listens to calls from their group, scores calls, adds notes.
• QA: sample-based access, no rights to change settings or perform mass exports.
• Security/Compliance: access to all recordings, right to export for investigations, ability to trigger legal hold.
• Administrator: manages the system and integrations but ideally cannot listen to content (if feasible).

Next — authentication. Often SSO/MFA, session rules and lockouts are not specified. Require corporate SSO and mandatory MFA for roles with export rights, session timeout and forced logout, password policies for local accounts (if any remain), and lockout after failed attempts.

A separate point is action audit. You need a log showing who searched, who listened, who downloaded, who changed settings, and from which device. The audit must be protected from ordinary admin edits and export of audit must be available on request.

Separation of duties and temporary access are often omitted. A practical approach: grant access to sensitive recordings by request, for a limited time and with a stated reason. For example, QA gets 48-hour access to specific calls for an incident, after which access is automatically revoked.

Finally, remote access. Specify whether it is allowed at all and under what conditions: only via VPN, only from managed devices, ban downloads to personal computers, restrict by IP or geography. These simple formulations often save long InfoSec approvals later.

Masking and data compliance

Risks usually arise not from the recording itself but from sensitive data present in audio and transcripts. In the requirements, explicitly list what you consider sensitive: IIN, card number and expiry, CVV, address, email, health data, salary information or internal investigation details.

Also state where masking must operate: in text (speech-to-text, agent notes, CRM fields) and in audio. For text it's usually enough to redact fragments with placeholders and restrict search on masked items. For audio, choose a clear approach: remove the fragment, replace it with a tone, or keep the original with strict access controls.

If you accept card payments by phone, specify a requirement for a recording pause during card entry. Define triggers (agent button, IVR mode, automatic detection) and system behavior on errors so the pause doesn't become a gap in quality control.

Rules for unmasking should be exceptional. Set rules such as:

• who can view the original (for example, security on request)
• whether dual approval is required (process owner + InfoSec)
• how the viewing is logged (audit, reason, case number)
• whether downloading the original is allowed or only viewing
• how quickly access is blocked if an incident is detected

Another often-missed point is transcript retention. Text is easier to search and copy than audio, so leaks often occur via transcripts. It can be safer to retain transcripts for a shorter period than audio and to tighten export rules.

Example: a complaint arrives and QA requests the recording. If the call contains IIN and address, a masked version is enough for the manager, while full access is given only to an authorized employee and appears in the log. This separation reduces risk and simplifies InfoSec and regulator approvals.

Search, metadata and speech analytics: what to request

If you don't describe search and metadata, the system quickly becomes a "sound archive" where finding the right call takes hours. A good rule: first describe how people will realistically find recordings (QA, complaint review, security), then list reports and analytics.

Metadata: what to record for each call

Fix a minimal set up front, otherwise some fields may be unavailable from the PBX/contact center or filled manually:

• customer number (ANI) and internal agent ID
• queue, direction, result (answered, missed, transferred)
• start/end time, duration, call ID and recording ID
• tags and categories (e.g. "complaint", "refund", "VIP") and who applied them
• flags for "sensitive data" (e.g. payment data) for masking

Then describe which fields come automatically, which are pulled from CRM, and what happens if a source is unavailable (call exists but no customer card).

Search and speech analytics: how to formulate requirements

Usually more than one search type is needed. Specify filters and UI responsiveness at expected volumes. A common set: search by time, number and agent, by queue/direction, by tags, plus full-text search in transcripts (keywords and phrases). If you need topics and classification, describe how models are trained and who owns quality.

Also require time synchronization: NTP support, a single timezone and acceptable timecode drift between audio, logs and metadata. Otherwise an incident logged as "10:15" may correspond to a recording marked "10:12."

Speech recognition quality should be treated as a process: run a pilot on your calls, set an accuracy metric on selected scenarios, list "difficult" conditions (noise, headsets, accents) and define an improvement plan. For multilingual setups list languages (Russian/Kazakh/English), auto-language-detection rules and handling of mixed-language speech.

Example: security searches for a call by complaint. They need a number and time range, a quick transcript search for a phrase, and an exact timestamp to match with access logs.

Exports for investigations: formats, traces, legal hold

Exports are needed infrequently, so they are often written as one line. Then, during an incident, you can't quickly and securely gather a case package. Predefine what counts as an "export" and the rules that apply.

Start by defining the package contents. Cases may require not only audio but transcript, metadata (number, agent, time, queue, call ID), and sometimes analytics results (tags, detected phrases, scores). Specify acceptable formats and a single container for the case package so it can be opened without the original system.

Even more important is the chain of custody: who requested the export, who executed it, where a copy is stored and who had access. Specify audit trail requirements and integrity checks.

Useful items to fix in the spec:

• audio, text, metadata and reports exported as separate files and as a single package
• automatic log: request, executor, time, list of files, justification
• integrity control: hash/checksum per file and for the whole package
• limits on mass exports: quotas, time limits, role-based restrictions
• rules for storing copies: retention, encryption, ban on "manual" transfer

Legal hold should be a separate item: enabling it for a case must block automatic deletion even if retention has expired.

Example: security investigates a leak and needs 23 calls for a week with transcripts and tags like "passport/card." Without legal hold some calls could be deleted by the retention policy and without an action log you can't prove who exported what.

How to gather requirements and document them in the spec: step by step

A good spec starts with clear use cases and responsibility boundaries, not with choosing Verint, NICE or an on-prem platform. If you don't fix those, unexpected requirements for storage, access or exports surface later and stall the project.

Collect requirements in steps:

1. Capture load and scope: calls per day, average duration, channels (telephony, softphone, contact center), departments and number of agents. Specify from which date recordings must be available and the retention horizon.

2. Describe usage scenarios as short stories: supervisor samples calls for quality, security searches by number and time, lawyers request a recording with evidence of integrity. For each scenario define who performs the action and what outcome is considered success.

3. Create a requirements matrix with priorities must/should/could and acceptance criteria. For example: "must: export a fragment in the specified format + action log" or "should: mask personal data fragments during playback."

4. Pre-agree integrations and RACI: PBX/contact-center, SSO/AD, SIEM, ticketing systems. Clearly assign who is responsible for network, certificates, backups and role administration.

5. Record constraints: bandwidth and network segmentation, available storage, encryption requirements, licenses and access/audit regulations.

A practical tip: before the final spec, run a 30-minute walkthrough of a complex case, e.g. an investigation with legal hold. If you can describe step-by-step how a recording is found, who confirms integrity, how it's exported and who appears in the audit log, the requirements are likely complete enough.

Typical spec mistakes that stall the project

The most common cause of delays is not Verint or NICE or hardware, but a spec that states goals without rules. At acceptance different departments realize they expected different things.

One retention number is almost always insufficient. Audio, transcripts, metadata (number, agent, queue), reports and logs often need different retention periods and storage rules. Without this you either run out of disks or keep too much and increase risk.

Second pain point — action audit. Many specs say "log actions" but don't specify what to log (playback, export, delete, privilege changes), who can view logs and whether logs can be altered. Without immutability requirements disputes are resolved "by trust."

Masking has the same problem: the requirement exists but rules don't. Decide where to mask (audio, text, player UI), for which roles and on which triggers (card numbers, IIN, passport data). Otherwise some users will see too much while others cannot work.

Exports and copy lifecycle are often forgotten. An export "for security" without formats, signature/hash, accompanying files and storage rules results in files traveling on USB drives and email.

Minimum to specify explicitly

• retention by data type and deletion conditions
• audit: event list, retention of logs, access and protection from edits
• masking: where, for whom, by what rules and how to verify
• exports: who can, in what form, how the chain of custody is recorded
• tests: restore from backup and failure scenarios (what success looks like)

Simple example: security requests a week's recordings by queue. Without legal hold and export format rules IT will export what it can, and a month later some recordings may have been deleted and file authenticity cannot be proven.

Short checklist before finalizing the spec

Before sending the spec for approval (especially if choosing Verint, NICE or on-prem), run this quick check. Projects often stall not because of recording itself but due to disputed data and access points uncovered during implementation.

Five questions that must have clear answers in the document, not "by default":

• what retention periods are required by call type and channel, and who approves exceptions (for claims and disputes)
• how records are deleted: by schedule, by event, on request, and how deletion is recorded (important for audits)
• who and how gets access: roles, separation of duties, SSO/MFA, and what actions are logged
• how personal and payment data are masked: what is masked, at which stage (recording, transcript, player), and who can unmask
• how exports for investigations are produced: format, signatures/hashes, action log, and how the chain of custody is protected

Also ensure acceptance tests are measurable, not "based on trust."

Acceptance criteria should be simple checks: restore a recording from archive, export a case with audit logs, demonstrate a "who listened/downloaded" report, and run a sample investigation with access limited to a subset of users.

Example: a bank agent disputes a transaction. You must quickly find the call, lock access, export recording and transcript with timestamps, and preserve evidence so it can be used internally and in external reviews.

Example scenario: investigating an incident without extra risks

A customer files a complaint: an agent allegedly gave incorrect contract terms by phone. QA needs to retrieve the call and understand what was said, while legal needs materials that can be used as evidence.

A user with the "investigation" role finds the recording by metadata: customer number, inbound line, agent ID, date/time range, call status (answered, transferred) and linked CRM ticket. The system should show an integrity indicator, for example a digital signature or hash, proving the file hasn't been modified since recording.

Access restrictions then apply. The agent and their manager can listen only in "playback" mode without download. Full export is permitted to two roles: security and legal — and only for the investigation's duration.

When materials are packaged for transfer, unnecessary data is masked:

• audio and transcript with redaction of card numbers, IIN, addresses, passwords and SMS codes
• an evidence package: original file, checksum, metadata, timestamp
• an action report: who searched, who listened, who exported, from which device
• legal hold active for the review period

After the case closes remaining artifacts include: an internal memo with the recording ID, the audit report, the export package with hashes, a record of who was granted access and when it was revoked, and a note on removing the legal hold. This scenario verifies that storage, access, masking and exports work together.

Next steps: pilot, capacity planning and rollout

When requirements define storage, access, masking and exports, don't rush to procurement. First validate them in a small scope. It's cheaper to fix architecture early than to rework it after launch.

Pilot with real scenarios

A pilot should reflect your reality: line types, load, roles and typical investigations. It answers whether the whole process works, not just recording.

Measure and verify:

• recording quality and coverage (including transfers and holds)
• search by metadata and response times
• correct masking and role-based access
• export process for investigations with traceability
• the real path from request to delivery (who, how long)

Capacity planning and rollout

For on-prem deployments calculate storage and server resources: concurrent channels, codec, average call length, retention periods, and headroom for indexing and speech analytics. Plan redundancy: where backups live, how restore is verified and what happens if a node fails.

Agree on support model and procedures: who creates user accounts, who approves access, how often audits are reviewed and who can initiate legal hold. If security needs to quickly pull a call chain, define who can request an export and who only confirms it.

If on-prem is required, plan server and admin workstation delivery and 24/7 support. This is convenient to discuss with a systems integrator like GSE.kz (gse.kz): they act as vendor and integrator and can help build infrastructure for recording, storage and operations without binding you to a single vendor.