Contact

Home Security and privacy

Security and privacy

At Ekata, respecting the individual rights of our data subjects is always top of mind. We provide identity verification and fraud prevention services worldwide to protect consumers and their identities – including in the EU where we offer GDPR compliant options to individuals. Our security and privacy team has been working for years to secure personal data and ensure individual rights, and will continue to do so.

Jump to Security information →
Jump to Privacy information →

Security overview

Ekata has been a trusted name in identity verification and fraud prevention for years, and we take that trust seriously. Long before security and privacy buzzwords entered the mainstream, we based our first information security program on ISO 27001:2005. Today, we still take a risk-based approach to information security, which is to say a practical one: we protect systems and data according to their sensitivity and exposure to threats. Our security and risk assessments are provided by third-party PCI Qualified Security Assessor companies to ensure an unbiased approach. And because we’re a Data as a Service provider, we also formally document our compliance with the AICPA Service Organization Controls (SOC) 2 principles of security, confidentiality, availability, and privacy.

Security FAQ

Ekata employs a risk-based information security program: we protect systems and data according to their sensitivity and exposure to threats. Our baseline risk assessments occur annually across both corporate and service environments, and are conducted by a third-party PCI Qualified Security Assessor. They include policy and procedure reviews, control design and functionality review, technical configuration analysis, network and web application penetration testing, and interviews with team members. All risks are documented with their associated vulnerabilities, controls, and recommendations for risk reduction.

These risk assessments feed into an enterprise-wide risk register which is maintained continuously. As new risks are identified, they’re formally documented and addressed. This whole process is overseen by our Information Security Officer and executive leadership.

Ekata employs role-based access controls based on need-to-know and least privilege. Each team member is assigned a primary role at hire, or transfer, which determines their access to systems and applications. Each role is formally defined, as its access. In order to gain access outside an individual’s role, an access request ticket must be submitted, approved, and provisioned.

Access control reviews are performed quarterly as part of internal audits conducted by our Information Security Officer.

Ekata has established a formal Incident Management Program that covers security, privacy, and availability incidents. For each type of incident, there are reporting, response, and retrospective requirements and supporting materials. Customer notifications are a formally documented aspect of each incident type.

Yes, Ekata employs a Qualified Security Assessor company to perform penetration tests annually against our web applications and external networks. The latest report is available to prospective and existing customers upon request.

Yes, Ekata employs an AlienVault SIEM across both service and corporate environments.

In addition to our dedicated security staff, Ekata employs a Managed Security Service Provider for 24/7 monitoring of our service and corporate environments.

Ekata employs a Multi-Factor VPN with per-client certificates for remote network access to both corporate and service environments. An IAM policy enforces MFA for our AWS console, and alerting is configured should it be disabled.

All Ekata, and most other Ekata properties, use HTTP Strict Transport Security, which forces all connections to use HTTPS. We currently only support TLS 1.2.

Ekata service environment is hosted in AWS across multiple availability zones and employs AWS Shield Advanced.

Yes. At hire, and annually thereafter, every software developer takes secure software development training, plus additional training relevant to their area of development. Web developers take OWASP Top 10 for instance, while backend database developers take courses on securing AWS database offerings.

Ekata employs AWS for its service infrastructure at the physical layer, and we review AWS SOC 2 Type 2 reports twice annually as part of our risk management program. Ekata corporate offices all use proximity badges with access logging, 24/7 video surveillance, and formal visitor management procedures.

What is Mastercard’s policy when it comes to reporting security vulnerabilities?

At Mastercard®, safety and security are foundational principles central to every part of our company and the innovative technology platforms and services we enable. We know that secure products and services are essential to the trust that our customers, cardholders, merchants and other partners place in us.

If you believe you have identified a security vulnerability, we encourage you to report this to us as soon as possible through our vulnerability reporting program. We’ll investigate all verifiable and legitimate reports and do our best to fix the problem as quickly as possible. 

What platforms and vulnerability categories are in scope?

Please visit https://bugcrowd.com/mastercard and https://bugcrowd.com/mastercard-vdp for an updated list of applications which are in scope for our Bug Bounty program. Certain applications are open in an “invite only” mode and may not show up on the list of public Bug Bounty programs. Mastercard invites selected researchers for such programs based on their technical expertise and rankings on the Bugcrowd leaderboards.

What if I identify vulnerabilities or issues outside of these areas?

Monetary rewards are offered to external security researchers if they identify an issue on one of the in-scope platforms. Compensation depends on the severity and impact of the identified issue. Mastercard reviews each identified vulnerability and reserves the right to reward submissions made on out-of-scope assets. We encourage researchers to submit identified vulnerabilities on out-of-scope assets on the https://bugcrowd.com/mastercard-vdp program.

What is the reward process for reported vulnerabilities?

You can submit potential security vulnerabilities to us through our Bug Bounty programs (on Bugcrowd.com) for consideration of rewards. Reward-related details are available on https://bugcrowd.com/mastercard. Please note that information provided through a Mastercard email address (security@mastercard.com) is not eligible for compensation under our vulnerability reporting program.

Privacy overview

At Ekata, a Mastercard company, nothing is more important than the success of our customers and the protection of our customers’ data. To support that mission, Ekata and Mastercard have established a comprehensive privacy and data protection program. We dedicate significant global resources to ensure compliance with applicable data protection laws and we have embedded privacy and data protection into the design of our products and services. We know you may have questions about Ekata’s approach to privacy and the Data Processing Agreement (“DPA”) that Ekata offers to its customers. To help you develop a better understanding of the Ekata DPA, we have created this FAQ to answer some of the most common questions we are asked. All defined terms used in this FAQ are as set out in the DPA.

For additional information about Mastercard International Incorporated and its affiliates’ (collectively, “Mastercard”) commitment to Privacy and Privacy Notice, please see here.

Privacy FAQ

Yes, Ekata maintains an internal privacy policy and annual privacy training for all team members.

Yes, Ekata offers a DPA to its customers here. However, not all customer agreements will utilize this DPA; use cases will vary. The DPA is an agreement that sets out the legal framework under which Ekata Processes Personal Information, including those it collects from customers to provide the Ekata services. The DPA is an addendum or exhibit to the Principal Agreement, i.e., a Master Services Agreement (‘MSA’), etc., between Ekata and its customer(s).

The Ekata DPA is specific to Ekata’s multi-tenant services and covers our processes in relation to these. For example, the DPA covers our processes around privacy-related notifications, audits, certifications, security measures, and sub-processing activities, all of which are aligned to the way in which Ekata’s services and its multi-tenant infrastructure work. The Ekata DPA is also drafted to seamlessly interoperate with the MSA and other relevant Ekata and Mastercard agreements.

Ekata’s DPA is applicable globally and sets out relevant legal obligations and commitments related to the processing of Personal Information in relation to the provision of the Ekata services. For ease of reference, it uses certain terminology from specific privacy and data protection laws, e.g., “Controller” and “Processor” from the European Union’s General Data Protection Regulation (“GDPR”) which are recognized globally. The DPA also includes a specific addendum to address the United States Privacy laws. There may be other addenda added to the DPA, as privacy regulations continue to evolve globally.

For Customers that only operate within the European Union, we have a DPA that is specific to that region.

Yes, the majority of the DPA applies to Customers regardless of their connection to the European Economic Area (“EEA”), Switzerland, and/or the United Kingdom (“UK”) (together, “Europe”). Most of the commitments in the DPA are driven by general privacy requirements in all data protection laws globally and are not specific to European laws only.

Ekata acts as the Controller with respect to Personal Information subject to GDPR and similar laws submitted by customers to Ekata’s services. The customer either acts as a Controller or a Processor of such Personal Information. This is set out in Section 2 (“Roles of the Parties”) of the DPA and Section 4 of the EU Addendum.

Ekata must control the purposes and means of the processing of Personal Information from Customers  to support the ongoing improvement of Mastercard’s fraud and security products and enable full capability to return more consistent, reliable results for our customers. For example, Ekata utilizes the Personal Information submitted by customers through a query to the service (“customer query data”) to power the Ekata Identity Network, which improves the Ekata product for all customers. The purpose and scope of processing  of Personal Information provided to Ekata by customers for the improvement of Ekata’s fraud prevention products  exceeds the notions of a traditional “processor” role as contemplated under GDPR (and other privacy laws). Additionally, as Ekata was recently acquired by Mastercard, the customer query data will be used to support various Mastercard fraud prevention products.

Ekata’s DPA represents our global commitment to the protection of our customers’ data. As digital transactions are borderless and global, this document includes references to the privacy statutes in many global markets, including the US, EEA, UK, Brazil, Argentina, among others. If you don’t have business in those countries today, the document stipulates that language governing those countries will not apply. Ekata will not remove that language from the agreement. It is rendered moot to the extent your business does not enter additional markets  but protects both companies in the event an individual from outside the customer’s typical markets  should even attempt to do business with your company, known or unknown to your current safeguards.

For the trial to be successful, the customer query data – including Personal Information – needs to be ingested into the Network in a production environment to receive Network signals and demonstrate full product efficacy. The DPA survives the trial and is applicable to the services at commercialization.

Data Subject Requests and Ekata Data FAQ

Many data privacy laws around the world guarantee their residents certain rights relating to their Personal Information and how companies may handle it – Data Subject Rights. To exercise these rights, the individuals whose Personal Information is being processed (“Data Subjects”) must submit a Data Subject Rights request to the company, and if the request is valid, the company is legally obligated to take the requested action and fulfill the request. Some of the most common Data Subject Rights requests are the rights to request a copy of, correct, stop processing, or delete Personal Information. The U.S. states of California and Virginia have recently added the right of an individual to request that a company stop selling their Personal Information if the company is a Data Broker.

Ekata responds to Data Subject requests to exercise rights granted to Data Subjects under global data protection laws, including the General Data Protection Regulation and U.S. state privacy laws, as applicable.

Our third-party data providers are contractually required to provide Data Subjects with the ability to exercise their data protection rights, such as an individual’s right to access or delete their information. Further, our data providers are required to notify Ekata of Data Subject requests. When Ekata receives this notification from the data provider, we make the required legal assessment and fulfill valid requests.

Individuals (or their agents, if applicable) may submit requests to Ekata using any of the methods appropriate for persons in each jurisdiction listed in our Privacy Notice. California and Virginia residents may also click the “Do Not Sell My Personal Info” link at the bottom of Ekata’s website to submit a request using our webform.

Yes, on occasion. We evaluate each bulk submission on a case-by-case basis for validity and applicability. Sometimes, we receive bulk requests from third parties who have been engaged by Data Subjects to submit requests on their behalf. We might also receive bulk requests from our third-party data providers, or from certain customers. Depending on the situation, we may handle each bulk request differently.

When a Data Subject submits a request that requires Ekata to delete or stop processing the individual’s Personal Information, we remove that information from our Identity Network and Identity Graph databases that power our products. When this has occurred, and a customer submits a query requesting information about that individual, the response returned to the customer is “Null,” or there may be no result at all if the query is part of a historical batch test. Unfortunately, this means that the query response will not help the customer in making a fraud prevention decision.

Yes, Data Subject requests, especially bulk requests, can impact performance metrics for Ekata Services. If, for example, Ekata has recently executed a bulk Data Subject request to delete or stop processing Personal Information, customers may see a dip in performance as a result of the increase in “Null” responses.

Yes, it is possible that bad actors could submit Data Subject requests in order to remove their Personal Information from fraud prevention services and make detection of their actions more difficult. However, global data protection authorities have generally found that this risk is less important than the rights of all individuals to have the ability to control their Personal Information.

Sub-processors FAQ

Yes. Ekata may share the Personal Information we receive when customers use our Services with our subsidiaries and affiliates that are part of the Mastercard group of companies. We may also share Personal Information with our service providers who perform services on our behalf. Examples of our service providers include analytics providers, data storage providers, and payment processing providers. We require these service providers to only process the Personal Information they receive in accordance with our instructions and as necessary to perform services on our behalf, to comply with legal requirements, and to protect the information with appropriate security measures.

An effective and efficient performance of Ekata’s services requires the use of Sub-processors. These Sub-processors can include Affiliates of Mastercard, Ekata, and/or other third parties such as vendors or service providers. Ekata’s use of Sub-processors may require the transfer of Customer Data to Sub-processors for purposes like hosting Customer Data, providing customer support, and ensuring the services are functioning properly.

European Data Transfers FAQ

All Personal Information can be accessed by Ekata systems from the United States. As access effectuates a “transfer” under GDPR, all Personal Information submitted to Ekata and stored in Ekata’s systems is transferred to the U.S.

Under EU Data Protection Law, Personal Information cannot be transferred outside of Europe unless (i) the importing country has been deemed adequate by the relevant governmental body; or (ii) the data exporter has appropriate safeguards in place to ensure that the Personal Information transferred is subject to an adequate level of data protection. The “appropriate safeguards” include transfer mechanisms such as standard data protection clauses (i.e., the Standard Contractual Clauses) and binding corporate rules.

Depending on the specific Services the Principal Agreement, Ekata may transfer data based on its Binding Corporate Rules (“BCRs”) – company-specific, group-wide data protection policies approved by data protection authorities to facilitate transfers of Personal Information outside of Europe within the Mastercard group. Some older agreements may rely on Standard Contractual Clauses to authorize these data transfers.

Ekata does not currently offer data localization options for any Ekata Services, though our product teams are working on these options for the future. The current configurations of the Ekata Services do require Personal Information from the EU to be transferred to and/or accessed from the United States.

Mastercard’s Privacy and Data Protection team assesses government data requests (“GDRs”) that involve Personal Information on a case-by-case basis. In particular, the team will establish whether the GDR is (i) legally binding; (ii) based on clear, precise, and accessible rules; (iii) necessary and proportionate; (iv) subject to independent oversight by regulators and/or the national judiciary system; and (v) subject to effective remedies for the affected individuals. Only when we are satisfied that the legal process is valid and appropriate, and when we are convinced that the GDR does not prevent Ekata from fulfilling its obligations under Mastercard’s Binding Corporate Rules and does not have a substantial effect on the guarantees provided by them, do we deliver the narrowest possible set of data required to be responsive to the GDR. If we do not manage to resolve the conflict of laws, the Privacy and Data Protection team will use its best efforts to put the GDR on hold for a reasonable delay in order to consult with the Belgian Data Protection Authority on how to resolve it.

Technical and Organizational Measures FAQ

The default treatment of Personal Information from Customers is the data is pseudonymized and encrypted.

Ekata maintains appropriate technical and organizational measures to protect Customer Data, including but not limited to:

Physical access control

Technical and organizational measures to prevent unauthorized persons from gaining access to the data processing systems available in premises and facilities (including databases, application servers and related hardware), where Personal Information are processed, include:

  • Establishing security areas, restriction of access paths;
  • Establishing access authorizations for employees and third parties;
  • Access control system (ID reader, magnetic card, chip card);
  • Key management, card-keys procedures;
  • Door locking (electric door openers etc.);
  • Security staff, janitors;
  • Surveillance facilities, video/CCTV monitor, alarm system;
  • Securing decentralized data processing equipment and personal computers.

Virtual access control

Technical and organizational measures to prevent data processing systems from being used by unauthorized persons include:

  • User identification and authentication procedures;
  • ID/password security procedures (special characters, minimum length, change of password);
  • Automatic blocking (e.g., password or timeout);
  • Monitoring of break-in-attempts and automatic turn-off of the user ID upon several erroneous passwords attempts;
  • Creation of one master record per user, user master data procedures, per data processing environment.

Data access control

Technical and organizational measures to ensure that persons entitled to use a data processing system gain access only to such Personal Information in accordance with their access rights, and that Personal Information cannot be read, copied, modified or deleted without authorization, include:

  • Internal policies and procedures;
  • Control authorization schemes;
  • Differentiated access rights (profiles, roles, transactions and objects);
  • Monitoring and logging of accesses;
  • Disciplinary action against employees who access Personal Information without authorization;
  • Reports of access;
  • Access procedure;
  • Change procedure;
  • Deletion procedure.

Please also see Ekata’s dedicated Security page detailing our compliance certifications and approach to security, or Annex 1 to the DPA.

Additional Resources FAQ

  • Ekata’s Privacy Notice can be found here.
  • The applicable DPA for Ekata’s products can be found here.
  • Ekata has a dedicated Security page.

If you have additional questions, please contact your Account Manager.

Security Breach Notifications FAQ

Ekata maintains security incident management policies and procedures, which are described in the applicable Security FAQ (available here). In Section 9.1 of the DPA (available here). Ekata commits to notify Customers without undue delay after becoming aware of a Personal Information Breach.

If your organization is impacted by a security breach, your organization’s Security Contact(s) will be notified. Steps on how to create and maintain your Security Contact List are available here.