Data Handling & Security
By retaining transaction record history, those responsible for managing Aerialink gateway and financials are provided the means to monitor transactions and financial records, resolve problems, forecast required infrastructure and analyze operations.
Furthermore, the retention of records enables Aerialink and Clients to comply with various requirements to evidence mobile user’s consent to receive text messaging (opt-in) or to unsubscribe from text messaging (opt-out), the following applies:
- MMA’s (Mobile Marketing Association) Consumer Best Practices Guidelines section 1.8-2: Independent of method of entry (SMS, MMS, Web, WAP, IVR) opt-in and opt-out records - including single, double and triple opt-in records – should be retained from the time the subscriber opts-in until a minimum of six months after the subscriber has opted-out of the program (minimum opt-in archiving period is one calendar year). These records should be made available to the aggregator or carrier upon request.
- FCC TCPA (Telephone Consumer Protection Action): Express written consent is granted for a specific telephone number, and it is recommended that records are kept for a minimum of five years and maintain a record of mobile users’ direct request to opt-out of receiving future marketing messages also for five years.
The regulation requirements outlined above dictate how long our mobile data records should be retained at a minimum. Aerialink record retention is permanent unless otherwise requested by Client. The entire transaction won’t be purged, however the message content, the location coordinates and the mobile number may be purged from Client’s records upon request.
Aerialink maintains messaging transactions in its data center for the duration of a message’s lifecycle (maximum of 96 hours except in rare cases). After this initial period has concluded, the messages are then maintained until the end of the billing cycle. The transactions are then archive within thirty-to-sixty days. Transactions are still available upon request after they have been archived.
Aerialink provides two storage and archiving options for the “content” of message transactions or “data points” of other transaction types, such as location services:
Data Encryption: default storage type
Data Purge: available upon request. Customers can set predefined timeframes upon which the content or other specified data will be purged from the chosen fields within the record.*
\Transaction records are maintained to support billing requirements. It is thereby not possible to completely purge or delete transaction records.*
Client may fill out a Mobile Data Destruction Form and submit the request to email@example.com. The Database Administrator is responsible for the electronic records/fields destruction and scheduling, based on Client request. Data will be fully destroyed 30 days after deletion due to backup and recovery procedures. Electronic record destruction will be suspended immediately, upon any indication of an official investigation or when a lawsuit is filed or appears imminent. Destruction will be reinstated upon conclusion of the investigation.
To protect against unauthorized access, all server access is logged and monitored. All servers require VPN RSA tokens for access. Internet/External End Points are exposed only via specific secured ports on separate infrastructure than the actual servers.
Each customer account has a private instance in our cloud server environment. Our gateway connects to the inter-carrier network via IPSEC Tunnel. Connection monitoring is in place and automatically reports status. HTTPS TLS Standard Bank Level Security is used to secure user access to the platform and sessions.
All requests to the Aerialink API over HTTPS are processed using High-Grade Encryption SHA 256 RSA with a 2048 Bit Algorithm. The use of SSL (Secure Socket Layer) via HTTPS is required for requests to be processed with this encryption level. We highly recommend HTTPS connections over HTTP to ensure a secure and private connection between your application server and our network. Aerialink’s support for non-HTTPS requests will be phased out at a future date. (currently, this resides https://docs.aerialink.net/api/v4/authentication/)
Two-factor authentication is used for remote access to our API & Gateway. A 3rd party authentication tool is integrated into our platform, which generates the password credential. User may re-generate a new secret at anytime. The gateway is not accessible without these credentials. The “key” is the first point of verification and the “secret” is the second point of verification. Whitelisting on the gateway firewall requires customer’s’ IP server address which is also used for authentication. In addition, customer must use our host address in the API for gateway access. The combination of these 4 verification methods provides a highly secure access point.
Perimeter controls are put in place to prevent/detect/eradicate malware (viruses, spyware, etc.) from our internal systems. We use the Cisco ASA Firewalls solution to manage this.
Configuration management controls are used to keep our platform and related systems current, including patches. We utilize both GIT and SVN for source control management, branches and rollbacks.
Reporting and logging is performed on the gateway platform, each application and each database. The logs have individual accountability; can be used for problem identification, and data extraction. The logs are protected against data alteration and unavailability. Event reconstruction is also accommodated. Access to logs requires a secured user login via HTTPS. All logs are maintained for six months minimum within our redundant and failover Cisco appliances.
Data is stored in an off-site facility with data retention via AWS cloud services. We have both internal and external recovery sites, both hot and warm.
This page was last updated 1539620611280