Responsible Platform Initiatives

Data Protection Security Requirements

Here you can find security requirements to help with the data protection questions in the data acesss renewal assessment.

These questions are the same as the ones in the individual data protection assessment being sent out after January of 2025.

These data security requirements are intended to provide helpful information and assist you in completing the data protection section of Meta’s data access renewal assessment. For any given question, please note there may be more than one way to demonstrate that you meet our requirements. Only a member of Meta’s review team can make a final determination on whether the evidence provided meets the requirements of the assessment. In addition to using this guide, we recommend consulting with your Chief Information Officer, the person with an equivalent role within your organization, or a qualified cybersecurity firm when preparing your responses to ensure your responses are complete and accurate.

Something Went Wrong
We're having trouble playing this video.
Learn more

A subset of the data access renewal assessment is focused on Platform Term 6, which outlines data security requirements. We recommend you utilize this document to understand the expectations, requirements, and related evidence with respect to data security use and processing as defined in Meta Platform Terms. `

Preparing to Answer Data Security Questions

Data Flows

Create a data flow diagram or description that shows how your app or system processes Platform Data.

  1. Client side: Include all client software, such as browsers, mobile devices, and other supported device types.
  2. Server side:
    • Identify components where Platform Data enters or exits the server environment (e.g., web listeners and REST APIs).
    • Identify components where Platform Data is written to persistent or durable storage (e.g., databases, disks, or log files).
    • Specify the hosting model (e.g., self-hosted, IaaS, PaaS, BaaS, or hybrid).

To meet our requirements, the data flow diagram or description should include:

  1. Where Meta API access tokens are generated, transmitted, stored, and renewed (if applicable).
  2. How you fetch Platform Data from Meta's APIs, including PII like name, email address, gender, birthdate, and other user data.
  3. How you use, store, and transmit this data.
  4. Any 4th parties to which Platform Data is sent.

Preparing Evidence

When submitting evidence to support your data security measures, please refer to the Evidence Guide provided in this document for examples of acceptable evidence. We accept common document file types, screenshots, and screen recordings. Ensure that files are not password protected and do not exceed 2 GB each. Accepted file types include .xls, .xlsx, .csv, .doc, .docx, .pdf, .txt, .jpeg, .jpg, .png, .ppt, .pptx, .mov, .mp4, .zip, and .zipx.

Redacting Sensitive Data

Before submission, remove any sensitive data from your evidence. This includes, but is not limited to:

  • Health and financial data
  • IP addresses, passwords, credentials, and access tokens
  • Encryption keys and physical addresses
  • Personally Identifying Information (PII) such as names, email addresses, user IDs, birthdates, and location data
  • Any data potentially identifying individuals indirectly, such as cultural, social, or political identities
  • Details of vulnerabilities, especially those involving children under the age of 13

Types of Evidence Required

Meta requires two types of documentation for each data security question:

  1. Policy or Procedure Evidence: This should be a document detailing your data security policies or procedures that align with Meta's standards. It can be an excerpt from internal policies, part of an internal wiki, or a newly created document.
  2. Implementation Evidence: This should demonstrate the practical application of your policies or procedures, such as tool configurations or screenshots showing the implemented measures.

Guidelines for Evidence Submission

  • Policy or Procedure Evidence: Must clearly articulate how your measures meet or exceed Meta's requirements. Only include relevant sections necessary for the review.
  • Implementation Evidence: Provide screenshots or screen recordings that accurately represent how you have applied the security measures. Ensure the evidence is as detailed as the examples provided by Meta.

Backend Storage, Data Stored, and Hosting Questions

All questions

backendstorage-8, datastored-8.a, hosting-8.b, hosting-8.b.i

Summary

In order to perform our reviews accurately, we need to first understand how Platform Data is processed and stored by your system or application.

This section asks if you store Platform Data in a backend environment, and if so:

  • Which specific Platform Data attributes
  • What backend hosting approach(es) are used

Changes from prior version

  • You will now be asked to indicate what Platform Data attributes you store in your backend environment.
  • You will also be asked to indicate what hosting solutions/infrastructure you use to process Platform Data in your backend environment.

Additional guidance

None

External resources

Not familiar with security in server or backend environments? Review these resources.

Evidence examples

Developers are not required to provide evidence in response to this question.

Backend Encryption and Hosting Security Questions

All questions

backendencryption1-9a, backendencryption2-9.a, backendencryption-9.b, backendencryption-9.b.i, backendencryption-9.b.ii, hostingsecurity-9.c.i, hostingsecurity-9.d.i

Summary

Encryption at rest protects Platform Data by making the data indecipherable without a separate decryption key. This provides an additional layer of protection against unauthorized read access in cloud or server environments where Platform Data tends to be concentrated.

You must encrypt all Platform Data stored within your backend environments. You may be asked to provide policy/procedure documentation and screenshot proof to demonstrate you have implemented this control.

This section asks if Platform Data stored in your backend environment is protected with encryption at rest or another acceptable approach to reduce the risk of data loss.

Changes from prior version

  • If you only store Meta User IDs or hashed User IDs in your backend environment, you are not required to answer these questions.
  • If you do not protect Platform Data in your backend environment with encryption at rest, you will be asked if your hosting provider has an ISO 27001 or SOC 2 certificate that meets certain criteria (Hostingsecurity-9.c.i, hostingsecurity-9.d.i).

Additional guidance

Backendencryption-9.b.i, backendencryption-9.b.ii Requirements

You must encrypt all Platform Data stored within your backend environments. You may be asked to provide policy/procedure documentation and screenshot proof to demonstrate you have implemented this control.

Policy/Procedure Evidence Implementation Evidence

Backendencryption-9.b.i - Provide a written explanation (e.g., a policy or procedure document) that states ALL Platform Data is encrypted at rest, including back-ups if necessary.

backendencryption-9.b.ii - Provide one or more screenshots showing your implementation of encryption at rest. For example, one or more of these:

  • A configuration in a dashboard/ console
  • A graphical user interface (GUI) that shows encryption through code
  • Encrypted fields (please redact any unencrypted data in the screenshot).

Hostingsecurity-9.c.i, hostingsecurity-9.d.i Requirements

Policy/Procedure Evidence Implementation Evidence

hostingsecurity-9.c.i - Provide a written explanation that confirms your hosting provider’s ISO 27001 or SOC 2 audit had in-scope physical security and secure media disposal controls.

  • Confirm that your responsible hosting provider has demonstrated to an independent auditor that sufficient physical security and secure media handling controls are in place (i.e., ISO 27001:2013: Control A.11 for Physical and Environmental Security and Control A.8.3 for secure media handling, SOC 2 Type 2: Control CC6.4 for physical security and CC6.5 for secure media handling).
  • Provide the date that your hosting provider’s ISO 27001 or SOC 2 certificate issued. The certificate is invalid if the SOC 2 Type 2 issuance date is older than 1 year or if the ISO 27001 is older than 3 years compared to the date of your DPA dispatch.

hostingsecurity-9.d.i- Provide your hosting provider’s ISO 27001 or SOC 2 Type 2 certificate.

  • If you are not legally allowed to share the certificate itself, upload a written statement that contains the name of the auditor and the date the certificate was issued.

External resources

Not familiar with encryption at rest in a server or backend environment? Review these resources.

Evidence examples

hostingsecurity-9.b.i and 9.b.ii evidence examples

Device Storage Questions

All questions

devicestorage-10, devicestorage1-10.a, devicestorage2-10.a, devicestorage-10.a.i, devicestorage-10.a.ii,devicestorage-10.a.iii, devicestorage-10.a.iv, devicestorage1-10.b, devicestorage2-10.b, devicestorage1-10.c, devicestorage2-10.c, devicestorage2-10.b, devicestorage-10.ci, devicestorage-10.c.ii, devicestorage-10.d

Summary

If your organization allows Platform Data on devices like employee laptops or removable storage (e.g., USB drives), that data is at high risk of unauthorized access if the device is lost or stolen. We require developers to take steps to limit this risk to Platform Data.

If you don’t allow storage of Platform Data on devices, but it is still accessible to members of your organization, we require developers to take steps to limit unauthorized use/storage.

This question asks if you have technical or administrative controls to limit the risk of loss of confidentiality of Platform Data stored on organizational and personal devices.

Changes from prior version

Changed questionnaire to ask specifically whether technical or administrative controls are in place specific to protection of storage of Platform Data on organizational devices and removable media.

Additional guidance

devicestorage1-10.a, devicestorage2-10.a Requirements

This requirement applies to all developers that have at least one member that could process Platform Data on an organizational or personal device such as a work or personal laptop computer.

If you store Platform Data on organizational devices or removable media:

You must have EITHER technical controls OR administrative controls relevant to Platform Data stored on organizational devices (e.g., laptops) and removable media.

Acceptable Technical Controls:

Policy/Procedure Evidence Implementation Evidence

devicestorage-10.a.i - A written explanation (e.g., a policy or procedure document) that outlines you have implemented ONE of the following controls:

  1. Full disk encryption for all organizational devices where Platform Data is held, or
  2. Use of Data Loss Prevention software to monitor and log actions related to the stored Platform Data

devicestorage-10.a.ii - A screenshot that demonstrates you have implemented one of the accepted technical controls (see left). Please note the control must be enforced at an organizational level through a configuration dashboard, ruleset, etc. A screenshot of the control implemented on a single device will NOT be accepted.

Acceptable Administrative Controls:

Policy/Procedure Evidence Implementation Evidence

devicestorage-10.a.iii - Policy/procedure document (must be a file upload) that states BOTH of the following:

  1. The allowable business purposes for processing Platform Data on organizational or personal devices
  2. A requirement to delete the data when this purpose no longer exists

devicestorage-10.a.iv - Confirm that all people in your organization who may process Platform Data on organizational or personal devices:

  1. Have been informed of the acceptable use policy for this data
  2. Have acknowledged their understanding of this policy
  3. Are informed of this policy as part of their onboarding as new employees

Devicestorage1-10.b, devicestorage2-10.b, devicestorage1-10.c, devicestorage2-10.c Requirements

If you do not store platform data on organizational devices but it is still accessible to members of your organization, we require that you forbid storage of platform data on all organizational devices and removable media:

Policy/Procedure Evidence Implementation Evidence

devicestorage-10.c.i - A written policy/procedure document (must be an uploaded file) that clearly states that storage of Platform Data on organizational devices (laptops, tablets, etc.) and removable media (USB devices, phones, etc.) is forbidden.


Please highlight or circle the clause in your policy that relates to this control. If you have data classification and data handling policies to determine controls on platform data storage, please indicate how you have classified Platform Data.

devicestorage-10.c.ii - Confirm that all people in your organization:

  1. Have been informed of the policy prohibiting them from storing Platform Data on organizational or personal devices
  2. Have acknowledged their understanding of this policy
  3. Are informed of this policy as part of their onboarding as new employees

devicestorage-10.d Requirements

If you store Platform Data neither in a backend environment nor on organizational devices and removable media, please provide a data flow diagram to demonstrate how you are processing Platform Data. Your diagram should:

  1. Show how your app makes calls to Meta APIs, such as graph.Meta.com and identify all components that use Platform Data, including those that store, cache, process, or transfer Platform Data across networks
  2. Describe the primary use cases (i.e., flows that provide valuable outcomes to users of your app) that you support

External resources

Not familiar with encryption at rest on organizational and personal devices? Review these resources.

Evidence examples

devicestorage-10 evidence examples

Transit Encryption Questions

All questions

transitencryption1-11.a, transitencryption1-11.b, transitencryption1-11.d, transitencryption1-11.a.i, transitencryption1-11.a.ii

Summary

Platform Data transmitted across the internet is accessible to anyone that can observe the network traffic. Therefore it must be protected with encryption to prevent those unauthorized parties from being able to read the data.

  • Encryption in transit protects Platform Data when it is transmitted across untrusted networks (e.g., the internet) by making it indecipherable except for the origin and the destination devices
  • In other words, parties in the middle of the transmission would not be able to read Platform Data even if they can see the network traffic (this is also called a man-in-the-middle attack)
  • TLS is the most prevalent form of encryption in transit because it’s the technology that browsers use to secure communications to websites like banks

This section asks if you always protect Platform Data with encryption in transit when sending it over the Internet.

Changes from prior version

None

Additional guidance

This requirement applies to all developers who transmit Platform Data over the internet for any reason other than requests directly to Meta:

  • Platform Data must never be transmitted across untrusted or third party networks in unencrypted format including transmission of platform data to your cloud environment outside of a Virtual Private Cloud (VPC)
  • For all web listeners (e.g., internet-facing load balancers) that receive or return Platform Data, you must:
    • Enable TLS 1.2 or above
    • Disable SSL v2 and SSL v3
    • TLS 1.0 and TLS 1.1 may only be used for compatibility with client devices that are not capable of TLS 1.2 or greater
  • Meta recommends, but does not require, that encryption in transit be applied to transmissions of Platform Data that are entirely within private networks, e.g., within a Virtual Private Cloud (VPC)

transitencryption1-11.a Requirements

Policy/Procedure Evidence Implementation Evidence

transitencryption1-11.a.i - Provide a written explanation (e.g., a policy or procedure document) that demonstrates you enable TLS 1.2 encryption or greater for all network connections that pass through, or connect, or cross public networks where Platform Data is transmitted. Your policy should include the following:


  1. Platform Data is never transmitted without encryption
  2. SSL version 2 and SSL version 3 are never used

transitencryption1-11.a.ii - Provide evidence (e.g., a full screen capture of the results of a Qualys SSL report run against one of your web domains) that demonstrates you enable security protocol TLS 1.2 or greater for data in transit.

The table below summarizes encryption in transit policy for different transmission types:

Type of Transmission Encryption in Transit Policy

To and from end user devices (mobile phones, PCs, tablets, etc.) and the server or cloud infrastructure

  • TLS 1.2 or greater must be enabled for compatible devices
  • TLS 1.0 and 1.1 may be enabled for compatibility with older devices

To and from the server or cloud infrastructure and any remote server, cloud infrastructure, or 4th party service

  • TLS 1.2 or greater must be enforced

To and from components entirely within the private data center, server, or cloud infrastructure

  • TLS encryption is recommended but not required for Platform Data transfers that are entirely within a private cloud network

To and from Meta and any device, server, or cloud infrastructure

  • Out of Scope for Data Protection Assessment - Meta controls the TLS policy for these transfers

External resources

Not familiar with encryption in transit? Review these resources.

Evidence examples

transitencryption1-11.a evidence examples

Testing Questions - Application and Cloud Security Testing

All questions

testing1-12.a, testing-12.a.i, testing-12.a.ii, testing1-12.b, testing-12.b.i, testing-12.b.ii, testing1-12.c, testing-12.c.i, testing-12.c.ii

Summary

You must test for vulnerabilities and security issues so that they can be discovered proactively, ideally preventing security incidents before they happen

  • Developers write software and operate apps and systems to process Platform Data
  • These apps and systems may contain security vulnerabilities that malicious actors can exploit, putting Platform Data at risk
  • You must take steps to find and resolve these kinds of vulnerabilities

This section asks about steps you take to test your software and cloud configuration for vulnerabilities and security issues.

Changes from prior version

  • Added a question about the specific tool or process you use to test your software or backend environment for vulnerabilities.
  • Added a question about your approach for testing your cloud environment for security misconfigurations, if applicable.

Additional guidance

testing1-12.a, testing1-12.b Requirements

This requirement is applicable to all developers.

Policy/Procedure Evidence Implementation Evidence

testing-12.a.i, testing-12.b.i - Provide a written explanation (e.g., a policy or procedure document) that states how you test the software you use to process Platform Data for vulnerabilities and security issues.


The following testing procedures should all be included in your written explanation:

  1. Test for security vulnerabilities at least once every 12 months
  2. Have a process to triage the findings based on severity
  3. Ensure that high severity vulnerabilities, which could lead to unauthorized access to Platform Data, are remediated in a timely manner

testing-12.a.ii, testing-12.b.ii - You must have tested your software used to process Platform Data for security vulnerabilities by conducting ONE of the following:

  • A penetration test of your app/system, OR
  • A vulnerability scan / static analysis of your software

The following details should be included in your evidence:

  1. An explanation of the scope and testing methodology
  2. The date when the testing activity took place (To be acceptable, the date must be no earlier than 12 months prior to the date that we notified you about this assessment)
  3. If applicable, a summary of any unremediated critical and high severity vulnerabilities

Remove or redact sensitive information such as detailed vulnerability reproduction steps from the evidence before submitting.

Vulnerability Disclosure Program (VDP)

If you are operating a functioning Vulnerability Disclosure Program (VDP), e.g., using the BugCrowd, HackerOne platforms, or another platform meeting industry standards, you may present this as an alternative protection instead of a pen test or vulnerability scan. To demonstrate this, you must submit the following evidence:

Policy/Procedure Evidence Implementation Evidence

testing-12.a.i, testing-12.b.i - Provide a written description or policy/procedure document that describes your vulnerability disclosure program. Your document should state that:


  1. There are no exclusions to the scope of the VDP relevant to the way you process Platform Data
  2. Submitted (valid) vulnerabilities are assigned a severity score, e.g., using CVSS 3.1
  3. Vulnerabilities are resolved in a reasonable amount of time, typically fewer than 90 days after the submission date

testing-12.a.ii, testing-12.b.ii - Provide screenshot proof of use of your vulnerability disclosure program:


  1. A statement of scope and how that interrelates with the software used to process Platform Data, AND
  2. A report of the actual vulnerability submissions in the program over the past 12 months from your DPA dispatch date. The report should include the vulnerability title, submission date, resolution date (if resolved) and severity category / score. Our team will check whether or not that there is actual ongoing vulnerability research and reporting within the past 12 months prior to your DPA dispatch date, typically indicated by at least 1 valid vulnerability report per month. If you have more than one app, we would typically expect the number of vulnerability reports through your program to scale up proportionally.

Remove or redact sensitive information such as detailed vulnerability reproduction steps from the evidence before submitting.

testing1-12.c Requirements

If you store Platform Data in a backend environment hosted by a cloud provider, you must test your cloud configuration for security issues. This requirement applies irrespective of the hosting approach (e.g., BaaS, PaaS, IaaS, self hosted, or hybrid), except if you are using a no-code backend.

Policy/Procedure Evidence Implementation Evidence

testing-12.c.i - Provide a written explanation (e.g., a policy or procedure document) that includes all of the following:


  1. Test for security vulnerabilities at least once every 12 months
  2. Have a process to triage the findings based on severity
  3. Ensure that high severity vulnerabilities, which could lead to unauthorized access to Platform Data, are remediated in a timely manner

testing-12.c.ii - You must have tested the cloud environments you use to process Platform Data for security misconfigurations. The evidence you provide must include all of the following:


  1. An explanation of the scope and testing methodology
  2. The date when the testing activity took place (To be acceptable, the date must be no earlier than 12 months prior to the date that we notified you about this assessment)
  3. If applicable, a summary of any unremediated critical and high severity vulnerabilities

Remove or redact sensitive information such as detailed vulnerability reproduction steps from the evidence before submitting.

External resources

Not familiar with application and cloud security testing? Review these resources.

Evidence examples

testing1-12 evidence examples

Access Token and App Secret Questions

All questions

accesstoken-13.a, appsecret-13.b, accesstoken-13.c, accesstoken-13.c.i, accesstoken-13.c.ii, appsecret-13.d, appsecret-13.d.i, appsecret-13.d.ii

Summary

App secrets and access tokens are fundamental to the security of how Meta APIs make decisions about what actions to allow. If an unauthorized party gains access to these credentials they could call Meta APIs - impersonating the real developer - and take any of the actions that we have granted the app (e.g., reading data from Meta APIs about an app’s users).

  • You have access to sensitive credentials as a part of the use of Meta’s Platform. Specifically:
    • Access Token - When people authorize the app, the software gets a credential called an access token that’s used in subsequent API calls
    • App Secret - Meta shares an app secret with developers with the expectation that only trusted parties (e.g., app admins) within the organization have access to this secret
  • An unauthorized party who is able to read these sensitive credentials can use them to call Meta APIs as if they are you (this is sometimes called token impersonation) leading to unauthorized access to Platform Data
  • Therefore these credentials must be protected from unauthorized access to prevent impersonation

This section asks questions about how you protect these attributes on the client and server side, as applicable.

Changes from prior version

Refactored to ask about protecting app secret and access tokens on client and backend environments separately.

Additional guidance

accesstoken-13.cRequirements

This question pertains to protecting Meta User Access Tokens stored in your backend environment.

Policy/Procedure Evidence Implementation Evidence

accesstoken-13.c.i - Provide a written explanation (e.g., a policy or procedure document) that describes your approach to protecting Meta User Access Tokens:


Your written explanation should include:

  1. A description of how user access tokens are protected from unauthorized read access
  2. A requirement that user access tokens must never be written to log files in cleartext (unencrypted) form

accesstoken-13.c.ii - Provide screenshot proof that Meta User Access Tokens are:

  • Stored in a data vault / secrets manager OR
  • Encrypted at the application or field/column level

If access tokens are not encrypted/ protected server side, you must:

  1. Store the app secret in a vault (or is using a Key Management System - KMS) AND
  2. Enable the “Require App Secret” setting in their developer console

Make sure that you do not include (i.e., remove or redact) the plaintext values of any secrets or access tokens in the evidence that you submit.

accesstoken-13.d Requirements

This question pertains to storage of Meta App Secrets.

Policy/Procedure Evidence Implementation Evidence

Q3.1-13.d.i - Provide a written explanation (e.g., a policy or procedure document) that describes your approach to protecting the Meta App Secret. Your response should include:


  1. Description of how the app secret is protected from unauthorized read access On Server Side - ONE of the following must be true:
    • Must be in a data vault or a secrets manager, OR
    • Must be on a secure server in an encrypted format via app-level encryption (not stored in plain text,) OR
    • Must not be stored at all on the server side
  2. A requirement that the app secret must never be written to log files in cleartext (unencrypted) form

accesstoken-13.d.ii - Provide screenshot proof that the Meta App Secret is either:

  • Stored in a data vault / secrets manager OR
  • Encrypted at the application or field/column level

If the developer does not protect or encrypt the app secret

  • The “Desktop/Native” Type is enabled in their Meta developer console.

Make sure that you do not include (i.e., please remove or redact) the plaintext values of any secrets or access tokens in the evidence that you submit.

Acceptable Alternative Protections

  1. If you do not protect access tokens stored server side with a data vault or via app-level encryption, you may:
    1. Protect the app secret by using a vault or application encryption where the key is only accessible to the app
    2. AND configure the app to require app secret proof for all API calls to Meta
  2. If approach #1 above is not viable (i.e., cannot require appsecret proof because it would block certain necessary API calls), then Meta will consider any other controls that you have in place to limit the risk of unauthorized use of the access tokens compared to the the risk of misuse of stored access tokens

External resources

Evidence examples

accesstoken-13 evidence examples

MFA Questions - Protecting Accounts from Unauthorized Access

All questions

mfa1-15.a.i, mfa1-15.a.ii, mfa1-15.a.iii, mfa1-15.b.i, mfa1-15.b.ii, mfa1-15.b.iii, mfa1-15.e, mfa-15.e.iii, mfa-15.e.iv

Summary

A common technique used by adversaries to gain access to confidential data is to start by gaining access to tools that a developer uses to build or operate their app/system. Sophisticated tools exist to hack into accounts that are protected only by password and present the risk of account takeover attacks. The intent of these questions is to ensure developers have implemented multi-factor authentication to mitigate these risks.

This section asks about how you protect accounts against unauthorized access using multi factor authentication or another approach.

Changes from prior version

Refactored to ask about protecting against unauthorized access using multi-factor authentication or another approach for each of these separately:

  • Collaboration and communication tools
  • Code repository
  • Backend software deployment tools
  • Backend administrative console
  • Remote access to backend servers

Additional guidance

mfa1-15.a.i Requirements

Related to an organization’s processing of Platform Data, remote access to all tools listed above (if applicable) must be protected with multi factor authentication (i.e., not simply a password):

Policy/Procedure Evidence Implementation Evidence

mfa1-15.a.ii - Provide a written explanation (e.g., a policy or procedure document) that states your requirements for multi-factor authentication (MFA) or other measures to prevent account takeover.

Your explanation should include requirements for all access to any collaboration and communication tools, and code repositories.

mfa1-15.a.iii - Provide screenshot proof that MFA is enforced on ONE or MORE of the tools applicable to the environment that are listed above (i.e., collaboration tools and code repository)

Your evidence should show how you use authentication to protect all access to any collaboration and communication tools, and code repositories.

Policy/Procedure Evidence Implementation Evidence

mfa1-15.b.ii - Provide a written explanation (e.g., a policy or procedure document) that states your requirements for multi-factor authentication (MFA) or other measures to prevent account takeover. Your explanation should include requirements for all access to any collaboration and communication tools, code repositories, software deployment tools, and backend administrative tools.

mfa1-15.b.iii - Provide screenshot proof that MFA is enforced on ONE or MORE of the tools applicable to the environment that are listed above (i.e., collaboration tools, code repositories, software deployment tools, and backend administrative tools). Your evidence should show how you use authentication to protect all access to any collaboration and communication tools, code repositories, software deployment tools, and backend administrative tools.

Policy/Procedure Evidence Implementation Evidence

mfa-15.e.iii - Provide a written explanation (e.g., a policy or procedure document) that states your requirements for multi-factor authentication (MFA) or other measures to prevent account takeover. Your explanation should include your authentication requirements for all remote access to servers via a tool like SSH.

mfa-15.e.iv - Provide screenshot proof that MFA is enforced on ONE or MORE of the tools applicable to the environment that are listed above (i.e., remote access to servers via a tool like SSH) Your explanation should include your authentication requirements for all remote access to servers via a tool like SSH.

Acceptable Alternative Protections

Meta recommends that developers protect against account takeover by requiring MFA. However, when MFA is not used, developers must take other steps to protect against unauthorized access in line with industry best practices for password complexity rules (see The Center for Internet Security (CIS) Password Policy Guide here: https://www.cisecurity.org/insights/white-papers/cis-password-policy-guide).

Requirements for DPAs submitted PRIOR TO May 15, 2025

Policy/Procedure Evidence Implementation Evidence

mfa1-15.a.ii/b.ii/e.iii - Provide a written explanation (e.g., a policy or procedure document) that demonstrates you enforce:

  1. Password specific requirements
    • Enforce password length of at least 8 characters
    • Require at least one number and/or special character
    • Restrict password reuse, or formally define number of iterations before reuse is allowed.
    • Require minimum password age of 1 day (i.e., if a password is changed, the system doesn’t allow it to be changed again for 24 hours).
  2. Authentication backoff delays OR Automatic account lockouts with at most 10 failed login attempts

mfa1-15.a.iii/b.iii/e.iv - Provide a global configuration or dashboard demonstrating password complexity policies.

Requirements for DPAs submitted AFTER May 15, 2025

Policy/Procedure Evidence Implementation Evidence

mfa1-15.a.ii/b.ii/e.iii - Provide a written explanation (e.g., a policy or procedure document) that demonstrates you enforce:

  1. Password specific requirements
    • Enforce password length of at least 14 characters
    • Require at least one number and/or special character
    • Restrict password reuse, or formally define number of iterations before reuse is allowed.
    • Require minimum password age of 1 day (i.e., if a password is changed, the system doesn’t allow it to be changed again for 24 hours).
  2. Authentication backoff delays OR temporary account lockouts upon consecutive failed login attempts (CIS recommends temporary account lockout (15 minutes or more) after 5 consecutive failed attempts or time doubling throttling (in minutes) between each retry (0, 1, 2, 4, 8, etc.).
  3. Automatic hard account lockout (i.e., IT admin reset required) upon 10 consecutive failed login attempts.

mfa1-15.a.iii/b.iii/e.iv - Provide a global configuration or dashboard demonstrating password complexity policies.

External resources

Not familiar with protecting accounts from unauthorized access? Review these resources.

Evidence examples

mfa1-15 evidence examples

Maintaining Questions - Access Controls

All questions

maintaining-16, maintaining-16.a.i, maintaining-16.a.ii

Summary

Accounts are the basic unit of management for granting people access to systems, data, and administrative functions. Having good account management hygiene is an important part of preventing unauthorized use of accounts to gain access to Platform Data. The intent of this question is to ensure developers are following the principle of least privilege and have a systematic way for managing accounts, granting permissions or privileges, and revoking access when it’s no longer needed.

This section asks about the systems and processes you use to manage access to your systems / tools.

Changes from prior version

Refactored to ask a question about the specific processes you have in place for reviewing and revoking access under different circumstances.

Additional guidance

You must have a tool or process for managing accounts for each of the these tools/systems/apps:

  • Those used to communicate with one another, e.g., Slack or business email
  • Those used to ship software, e.g. code repository and
  • Administer and operate the system (as applicable to processing Platform Data)

You must regularly review (i.e., not less than once every 12 months) access grants and have a process for revoking access when: (1) it’s no longer required, (2) no longer being used, and (3) when a person departs the organization

Meta does not require:

  • That any particular tool be used – a developer may use a directory product like Google Cloud identity or Microsoft Azure Active Directory, a cloud product like AWS Identity and Access Management (IAM), or use a spreadsheet that is kept up to date regularly.
  • That there be a single consolidated tool for managing accounts across these various access types.

maintaining-16.a Requirements

Policy/Procedure Evidence Implementation Evidence

maintaining-16.a.i - Provide a written explanation (e.g., a policy or procedure document) that covers your account management practices. We expect this document to contain procedures for:

  • Revoking access that is no longer required
  • Revoking access that is no longer being used
  • Revoking access promptly when a person leaves your organization (e.g., when an employee resigns or is terminated)
  • Reviewing access at least once every 12 months

maintaining-16.a.ii - Provide evidence from AT LEAST ONE of the following tools or processes that is in place to manage accounts (or denote as not applicable to the environment):

  • Business email and collaboration tools
  • Code repository
  • Cloud/server deployment tools
  • Cloud/server administrative portal
  • Cloud/server remote login (e.g., SSH or remote desktop)

For example you could provide evidence that demonstrates people that have departed your organization have had their access to these tools revoked

External resources

Not familiar with access controls? Review these resources.

Evidence examples

maintaining-16 evidence examples

Patches and Mobile Questions - Keep Software Up to Date

All questions

patches1-17.a, updated-17.a.i, updated-17.a.ii, mobile1-17.b, mobile-17.b.i, mobile-17.b.ii, patches1-17.c, antivirus-17.c.i, antivirus-17.c.ii

Summary

Software components are routinely updated or patched to resolve security vulnerabilities, and eventually these components will reach their end of life when they are no longer supported. Developers who package or rely on these components must keep up to date to avoid running software with known vulnerabilities. Therefore, developers using Meta’s platform must have a systematic way to identify, prioritize, and apply patches for all relevant parts of their tech stack.

This section asks about the systems and processes you use to keep software up to date.

Changes from prior version

Refactored to ask about your approach for keeping different types of software up to date, in separate questions:

  • Third-party software in your backend environment
  • Third-party code in your mobile app
  • Other third-party software used by people in your organization to build and operate your app

Additional guidance

For the following software components, as applicable, you must have a defined and repeatable way of identifying available patches that resolve security vulnerabilities, prioritizing based on risk, and applying patches as an ongoing activity:

  1. Libraries, SDKs, packages, app containers, and operating systems used in a cloud or server environment
  2. Libraries, SDKs, packages used on client devices, e.g., within mobile apps
  3. Operating systems and applications used by members to build and operate the app/system, e.g., operating systems and browsers running on employee laptops

Meta does not require the use of any particular tool for these activities. It’s common that an organization would use different approaches for keeping different types of software up to date (e.g., libraries that are packaged with the app vs operating system updates for employee laptops).

This requirement applies irrespective of the hosting approach (e.g., BaaS, PaaS, IaaS, self hosted, or hybrid), although the set of components that you are responsible for keeping up to date will vary Start by identifying the in-scope types of software in the environment, e.g., Libraries, SDKs, Packages, Virtual Machine images, app containers, and operating systems, Browsers, operating systems, and other applications used by the employees / contributors.

You may have one or more tools that you use for the following activities:

  • Inventory - document via a screenshot or document that a tool or process that, ultimately, represents a list of in-scope libraries, packages, SDKs, containers, app servers and operating systems that need to be patched. There needs to be inventories for a representative of the software types (e.g., cloud app(s), client app(s), employee devices).
  • Identifying available software patches - a tool or process must exist for identifying security patches that exist that are relevant to the inventory.
  • Prioritizing - there needs to be a tool or process (e.g., Jira tickets, GitHub issues, tracking spreadsheet) by which relevant patches are assigned a priority
    • Patching
    • Document via a screenshot or document that demonstrates that, after relevant patches have been identified and prioritized, that they are then rolled out into the various destinations.
  • Include policies around time to resolve and use of End of Life (EOL) software.

patches1-17.a Requirements related to third-party software in your backend environment, if applicable:

Policy/Procedure Evidence Implementation Evidence

updated-17.a.i - Provide a written explanation (e.g., a policy or procedure document) that describes how you keep code and backend environments updated. Your response should describe that your patch management system:

  1. Has a defined and repeatable way of identifying patches in third-party software that resolve security vulnerabilities
  2. Prioritizes available patches based on risk (e.g., based on CVSS severity)
  3. Applies patches as an ongoing activity

updated-17.a.ii - Provide screenshot evidence that shows how you keep code and backend environments updated. This evidence can come in the form of:

  1. Dependency Scanners - The following details should be included in your evidence:
    • An explanation of the scope and testing methodology
    • The date when the testing activity took place (To be acceptable, the date must be no earlier than 12 months prior to the date that we notified you about this assessment.)
    • If applicable, a summary of any unremediated critical and high severity vulnerabilities
  2. OR a spreadsheet or equivalent tool for manually tracking what services you are using and what needs to be updated

mobile1-17.b Requirements related to third-party code in your mobile app, if applicable:

Policy/Procedure Evidence Implementation Evidence

mobile-17.b.i - Provide a written explanation (e.g., a policy or procedure document) that describes how you keep third-party code in your mobile app updated. Your response should describe that your patch management system:

  1. Has a defined and repeatable way of identifying patches in third-party software that resolve security vulnerabilities
  2. Prioritizes available patches based on risk (e.g., based on CVSS severity)
  3. Applies patches as an ongoing activity

mobile-17.b.ii - Provide screenshot evidence that shows how you keep third-party code in your mobile app updated. This evidence can come in the form of:

  1. Mobile dependency scans - The following details should be included in your evidence:
    • An explanation of the scope and testing methodology
    • The date when the testing activity took place (To be acceptable, the date must be no earlier than 12 months prior to the date that we notified you about this assessment.)
    • If applicable, a summary of any unremediated critical and high severity vulnerabilities
  2. OR a spreadsheet or equivalent tool for manually tracking what services you are using and what needs to be updated

patches1-17.c Requirements related to other third-party software used by people in your organization to build and operate your app, if applicable:

Policy/Procedure Evidence Implementation Evidence

antivirus-17.c.i - Provide a written explanation (e.g., a policy or procedure document) that describes how you keep third-party software and antivirus software on organizational devices updated. Your response should describe that your patch management system:

  1. Has a defined and repeatable way of identifying patches in third-party software that resolve security vulnerabilities
  2. Prioritizes available patches based on risk (e.g., based on CVSS severity)
  3. Applies patches as an ongoing activity

antivirus-17.c.ii - Provide screenshot evidence that shows how you keep third-party software and antivirus software on organizational devices updated. This evidence can come in the form of:

  1. A tooling configuration that shows how you push OS/software updates across your organization such as Chef, OR
  2. a tooling configuration that shows that antivirus software is set to automatically update across your organization, OR
  3. a spreadsheet or equivalent tool for manually tracking what services you are using and what needs to be updated

External resources

Not familiar with keeping software up to date? Review these resources.

Evidence examples

Patches and Updated evidence examples

Auditlog Questions

All questions

auditlog-22, auditlog-22.a, auditlog-22.a.i, auditlog-22.b, auditlog-22.b.iv, auditlog-22.b.iii, auditlog-22.c, auditlog-22.d, auditlog-22.e.1, auditlog-22.e.ii, auditlog-22.e.iii, auditlog-22.f.1, auditlog-22.f.ii, auditlog-22.g, auditlog-22.g.i

Summary

Without reliable log files it can be difficult to impossible for a developer to detect unauthorized access to Platform Data. Audit logs allow an organization to record the fact that an event occurred, e.g. that a particular user executed a query against database tables containing Platform Data. These logs can then support processes like triggering automated alerts based on suspicious activity or forensic analysis after a security incident has been identified. The intent of this question is to determine if developers have implemented controls around admin and application event logging to flag and escalate potential security incidents.

Changes from prior version

  • This section is new as of questionnaire v3.

Additional guidance

auditlog-22 Requirements

Policy/Procedure Evidence Implementation Evidence

auditlog-22.a - Provide a written explanation (e.g., a policy or procedure document)that describes your approach to collecting admin audit logs. Your response should:

  1. State admin logs are collected, AND
  2. Describe what events are logged (unsuccessful login attempts, auditing / deleting of audit admin logs, and granting / revoking access admin privileges to accounts)

auditlog-22.a.i - Provide screenshot evidence that shows how you collect admin audit logs. This evidence can come in the form of:

  1. A tool dashboard showing admin audit logs are being collected along with the type of WHAT events are audited, OR
  2. Directory listing of files that indicate they are admin logs with date stamps

Evidence provided must meet the following requirements:

  • Screenshots and logs must be within 3 months from the date you received your Data Protection Assessment
  • Redacted logs are acceptable as long as the event type and date are displayed

auditlog-22.b Requirements

Policy/Procedure Evidence Implementation Evidence

auditlog-22.b.iv - Provide a written explanation (e.g., a policy or procedure document) that describes your approach to collecting application event logs. Your response should:

  1. State application event logs are collected, AND
  2. Describe that you log the following attributes:
    • Event type
    • Date and time
    • Success or failure indicator
    • Meta user ID (when shared with you)

auditlog-22.b.iii - Provide screenshot evidence that shows how you collect application event logs. This evidence can come in the form of:

  1. A tool dashboard showing application event logs are being collected along with the type of WHAT events are audited, OR
  2. Directory listing of files that indicate they are application event logs with date stamps

Evidence provided must meet the following requirements:

  • Screenshots and logs must be within 3 months from the date you received your Data Protection Assessment
  • Redacted logs are acceptable as long as the event type and date are displayed

auditlog-22.e.1 Requirements

Policy/Procedure Evidence Implementation Evidence

auditlog-22.e.ii - Provide a written explanation (e.g., a policy or procedure document) that describes your approach to reviewing application event logs. Your response should:

  1. State application event logs are reviewed at least once every seven days, AND
  2. Describe the use of an automated solution/ program to review logs, eg. a security information and event management tool (SIEM)

Please note that due to anticipatedly large amounts of data we expect to be captured in application event logs, we will not accept responses that indicate reviews conducted are solely manual.

auditlog-22.e.iii - Provide screenshot evidence that shows how you review application event logs to find indicators of everyday security events or incidents that result in risk or damage.

Evidence provided must meet the following requirements:

An alert or output that demonstrates active use of an automated solution to detect and investigate security-relevant events found in your logs.

Acceptable Evidence examples:

  • Command line tool output highlighting suspicious events
  • A Jira ticket created as a result of log review findings
  • A Slack notification or alert triggered by the log monitoring tool

The key is that the evidence demonstrates active use of an automated solution to detect and initiate a follow up resulting from security-relevant events found in your logs.

auditlog-22.f.1 Requirements

Policy/Procedure Evidence (no screenshot evidence needed):

auditlog-22.f.ii - Provide a written explanation (e.g., a policy or procedure document) that describes your approach to reviewing admin logs. Your response should:

  1. State admin audit logs are reviewed at least once every seven days

Please note that manual review of admin audit logs is acceptable.

auditlog-22.g Requirements

Policy/Procedure Evidence (no screenshot evidence needed):

auditlog-22.g.i - Provide a written explanation (e.g., a policy or procedure document) that states how you investigate everyday security events or incidents in your backend environments where Platform Data is stored, which result in risk or damage to your audit logs. Your approach should describe:

  1. Steps to determine valid or invalid (positive or false positive) security event
  2. Escalation steps
Reminder: If a security event or incident occurs, our policies require you to promptly report it to us.

External resources

Not familiar with audit logs? Review these resources:

The following resources are not available free-of-charge, but offer valuable information and guidance:

Evidence examples

Q3.1-22 evidence examples

Security Processes Questions

All questions

securityprocesses-23

Summary

Ensuring personnel are properly trained in the safe handling and protection of confidential data, including Platform Data, along with recognizing signs of potential compromise will reduce the likelihood a security incident.

Changes from prior version

  • This section is new as of questionnaire v3.

Additional guidance

None

External resources

Not familiar with personnel security? Review these resources:

Evidence examples

Developers are not required to provide evidence in response to this question.