GDPR compliance

Last Updated : May 04, 2023 |
Prolog information
The following table lists GDPR requirements and how Avaya SBC supports those requirements.
GDPR Requirement
General GDPR Rule
Avaya SBC Support
Architecture Requirement for Inventory and handling of Personal Data
The architecture should define all interfaces and location for all the instances of personal data to be known. This facilitates the data controller to identify all personal data. The exception to this rule is for any data which is temporary and does not reside less than 24 hours in the system.
Avaya SBC documents all the interfaces and location of personal data in resident memory, data structures, files, CDRs, applications on cloud and distributed
In general any such data does not reside in Avaya SBC for more than 24 hours, so Avaya SBC is not exposed to the general applicability of this rule. Subsequent specific rules in this table may be applicable for the Avaya SBC.
Announcement and transparency on Personal Data Usage
Products that collect, process and/or store personal data and have a user interface to access data must have capability to announce or notify end user of such data.
Avaya SBC has user interface to modify data and also provides APIs to modify data. Avaya SBC does not modify or view personal data, and such notification from the Avaya SBC user interface is not required. In case of any such modification using APIs instead of UI, notification is not required for similar rational as above.
Avaya SBC is capable of playing an announcement in case of recording to notify the end user that recording is in progress.
Avaya SBC has a capability to interwork on DTMF digits on RTP as per 2833 telephone events to out-of-band SIP Signaling through INFO. In such an interworking case, Avaya SBC should provide an announcement after first collection of digits to notify the end user. In case Avaya SBC is relaying DTMF 2833 telephone events end to end, the role for playing the announcement is not applicable to Avaya SBC but to the entity which consumes the DTMF event.
Fulfillment of Data subject rights
The architecture should provide privileged users through user interface in case it allows to access, delete modify personal data. In case of absence of user interface, APIs should provide interface for privileged users
This rule is not applicable for Personal data which is temporary i.e. less than 24 hours.
Avaya SBC administers network interfaces, network properties, protocol interops and definitions, media rules and policies. Avaya SBC does not have any personal data and there is no requirement for privileged user to access personal data.
The personal data stored in Avaya SBC locally is in form of CDRs. In the case of a GDPR-compliant deployment, Avaya SBC should enable the radius interface. This forces all CDRs to be transported via a radius interface to a far end radius server. A high availability of radius interface is also supported in case far end radius server is temporarily unavailable. In case the deployment does not support high availability on the the radius interface, as soon as the radius server comes up all CDRs stored stored in Avaya SBC is pushed to the radius server. Avaya SBC does not store CDRs for more than 24 hours. CDRs should be accessed by privileged user only.
Indicators for call recording
The architecture should provide indications at start of recording for any audio or video call getting recorded.
The indication can be in form of visual indication or through announcement
If Avaya SBC records audio or video calls, Avaya SBC plays an announcement at start of recording to notify the end user.
Consent Management
The architecture should provide a user interface to notify consent on viewing/accepting personal data
This is not applicable for Avaya SBC because it does not store any personal data through its UI. In case of other mediums of personal data storage like traces, logs, and CDRs, the storage should be temporary and less than 24 hours beyond which this is redirected to another file server, remote syslog server, or radius server as applicable.
Personal Data Minimization - processing and storage
The product must only collect and process personal data necessary to perform the purpose of processing. If purpose can be reached without processing and storage of personal data, no processing and storage of personal data should take place
This is not applicable for Avaya SBC. Avaya SBC stores data in resident memory or uses network as storage and maintains minimal set of personal data for media and signal processing
The other mediums of storage like logs, traces and CDRs are considered as temporary storage in Avaya SBC.
Privacy by default
The product must ensure by default maximum privacy in protection of personal data
This is not applicable for Avaya SBC. Avaya SBC stores data in resident memory or uses network as storage and maintains minimal set of personal data for media and signal processing
The other mediums of storage like logs, traces and CDRs are considered as temporary storage in Avaya SBC.
Unique Access Control for Personal Data
The product shall have an effective, secure and customized access control
The Avaya SBC UI provides role based access control for any change in administration data.
Avaya SBC shall also provide role based access control for traces, logs and CDRs.
Security of Processing
The product must implement secured mechanism of processing personal data. This should also be applicable for transit data.
Avaya SBC handles signaling and media which exposes personal data of end user. This data is in transit and at Avaya SBC should be protected using standard encryption mechanism on TLS encryption for signaling and SRTP using SHA-1 and/or SHA-2 for media.
Anonymization and Pseudonymization
The product must define anonymization and pseudonymization techniques to help protect personal data
This is not applicable for Avaya SBC because all personal data is temporary and within 24 hours except for logs and traces which is described in Fulfillment in Logging and Tracking.
Fulfillment in Logging and Tracking
The product must describe fulfillment of the requirement around personal data for all logging and tracking mechanism and other solution level interface used for logging and tracking
This is not applicable for Avaya SBC as all logs/traces should not stay more than 24 hours within Avaya SBC and that is considered as temporary data. The logs and traces should be pushed to a remote syslog server on TLS within 24 hours or a lesser time interval administered.
Compliance after Restore operation
The product must comply to personal data compliance after applying a backup and restore
This is not applicable to Avaya SBC.
Documentation of product security
The product must have current security documentation as a prerequisite to any claims of compliance with Data Privacy regulation for Personal Data.
This is not applicable to ASBC as the security documentation is already available
178428-150
Use of Analytics and Diagnostics
The product must support anonymization of any personal data available in any diagnostic , tracing and analytics tool
SBC should anonymize all personal data in trace and logs. Example of personal data is calling party name/number, called party name/number, Identity of user, P-A-I, user name/password, content data in notifies