Evidence Guide: Data Protection Assessment

There are two acceptable paths for this requirement, including:

1. You are storing Platform Data on organization devices, AND applying controls to protect it.

   In this scenario, you must demonstrate that you have administrative controls in place to protect Platform Data on devices (organizational and personal) and removable storage. Your policy documentation must clearly state what employees are prohibited from doing with Platform Data. If you also enforce technical controls, provide evidence of those as well.

2. You prevent storage of Platform Data on organization devices, OR Meta Platform Data is never accessible to any member of the organization.

   In this scenario, you must demonstrate that you have administrative controls in place to prevent storage of Platform Data on organization devices or prevent members of the organization from accessing Meta Platform Data.

If you allow storage of Platform Data on these devices, you must have EITHER administrative controls (i.e., rules/policies) OR technical controls (e.g., disk encryption) relevant to Platform Data stored on organizational devices (e.g., laptops) and removable media.

Administrative Controls

If you do allow storage of Platform Data on organizational devices and removable media, the policy and procedure evidence you provide must include a document that states BOTH of the following:

1. Storage of Platform Data is only allowed when there is a clear and actionable business purpose, AND
2. Platform Data is deleted from organizational devices and removable media when the business reason for storing that data no longer exists.

Examples of acceptable evidence include:

• Documented policies outlining what employees are required to do, and prohibited from doing, with managed devices that access Platform Data
• A documented mechanism that facilitates organizational awareness of data handling guidelines for data generally, and Platform Data specifically, such as: a contractual agreement as a condition of employment, email reminders, and/or annual training

The documents you provide must clearly demonstrate how you enforce the controls listed above.

Examples of acceptable evidence:

Expand

Technical Controls

If you do allow storage of Platform Data on organizational devices and removable media, acceptable policy/procedure evidence of technical controls might demonstrate that you do ONE of the following:

• Block unmanaged devices from connecting to sensitive services (e.g., the production network)
• Enforce full-disk encryption on managed devices (e.g., BitLocker for Windows, FileVault for Mac) where Platform Data is stored
• Block removable storage (e.g., USB drives) from being connected to managed devices
• Use Data Loss Prevention (DLP) technology on managed devices to block improper handling of Platform Data (e.g., sending the data in an email attachment)

Acceptable implementation evidence of technical controls would include a screenshot that demonstrates you have implemented an acceptable control, such as full disk encryption or Data Loss Prevention software, for all devices storing Platform Data.

The evidence you submit must demonstrate that you enforce an acceptable control at the organizational level. A screenshot of the control implemented on a single device will NOT be accepted.

If you do not allow storage of Platform Data on these devices, you must have administrative controls relevant to Platform Data on organizational devices (e.g., laptops) and removable media. You must provide BOTH of the following:

1. Policy or procedure evidence: A written document that clearly states that storage of Meta 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 Meta Platform Data.

2. Implementation Evidence: A written statement that confirms you forbid the storage of Platform Data. That statement should be similar to the following: “All employees within my organization, who are subject to policy forbidding processing Platform Data on organizational and personal devices have been informed of that policy and acknowledged their understanding. All new employees are being informed of that policy as part of their onboarding.”

For all data transmitted over public networks, you must enable TLS 1.2 or greater. You must never allow Platform Data to be transmitted over public networks in unencrypted form (HTTP, FTP) and you must disable older, insecure encryption methods whenever possible.

This question requires both policy/procedure and implementation evidence. Even if you enable TLS 1.2 or greater, you will not meet this requirement if your evidence indicates that you support older, insecure encryption techniques.

If required for compatibility, TLS 1.1 and 1.0 are acceptable. Make sure you note that in your evidence if that applies to you.

Examples of acceptable evidence include:

• SSL Labs test result for each web domain that you return Platform Data to app clients, and TLS 1.2 or greater
• Screenshot of load balancer configuration(s) that demonstrate TLS 1.2 or greater is enabled
• For any third-party server you transmit data to, an explanation of how that third party configures their software client to only allow connections with TLS 1.2 or greater (e.g., a source code configuration for an HTTP client)

Examples of acceptable evidence:

Expand

You may be protecting Platform Data in transit using a different type of encryption besides TLS that is acceptable if the approach provides equivalent protection. If that's the case, submit the following details about the encryption you use:

• Whether you enable symmetric or asymmetric encryption
• Which encryption algorithm you use (e.g., AES, BitLocker, TDES, RSA)
• The minimum key length you enforce

All developers must have tested the software that processes Platform Data for vulnerabilities by conducting either a penetration test of the app/system, or a vulnerability scan/static analysis of the software. Additionally:

• The test must have been conducted within the past 12 months
• The output from the most recent test must show that there are no unresolved high-severity or critical vulnerabilities

If you are using a cloud hosting provider, regardless of the hosting approach, you must have also tested the cloud configuration for security issues.

This question requires both policy/procedure and implementation evidence. Your policy evidence must demonstrate the information Meta requires, including: how frequently you test, and a description of the tests you run.

Your implementation evidence should show that you have completed a penetration test or static application security test (SAST) tool execution. It must include:

• A description of the scope of the test
• The date that it was completed, which should be within the last 12 months
• A summary or list of vulnerabilities found during the test, including severity categorization (e.g., critical, high, medium, low, informational); Meta expects there to be no unresolved high severity or critical vulnerabilities
  

  If any critical and high severity vulnerabilities identified pose no risk of unauthorized access to Meta Platform Data, make note of this in your evidence.

• If you are using a cloud hosting provider (e.g., AWS, GCP, Azure, etc.):
  1. You must also submit evidence that you have undertaken a cloud configuration review such as NCC Scout Suite or AWS Config
  2. Ensure your report includes the important information that Meta requires: Date, findings, severity categorization, and no unresolved high severity or critical vulnerabilities
  3. If this is not applicable to your organization, include a document in your submission that explains why a cloud configuration review is not applicable

Examples of acceptable evidence:

Expand

Expand

Remember to remove or redact sensitive information from the evidence, including detailed vulnerability reproduction steps, before submitting.

You must protect the Meta API access tokens and Meta's app secret against impersonation and unauthorized access. Specifically, you must do the following for each:

This question requires both policy/procedure and implementation evidence. You must include:

• Documentation about the policy for protecting Meta API access tokens and the app secret
• An attestation that you do not not persist any Facebook access tokens (i.e., that you only store access tokens in transient memory)
• If the app processes Meta access tokens server-side, include evidence that demonstrates the protections you take; e.g., submit implementation evidence to demonstrate that you: use a data vault, store the values in an encrypted format, and/or configure your app to require app secret proofs
  • E.g.: include evidence of tools in place, such as: Vault by Hashicorp, GCP Firebase, Ansible

Examples of acceptable evidence:

Expand

Expand

Examples of unacceptable evidence include statements such as the following, neither of which provide sufficient protection:

• “We use environment variables.”
• “We hardcode these values into our source files in our code repository.”

Remember to remove or redact sensitive information from the evidence, including detailed vulnerability reproduction steps, before submitting.

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 using a vault or application encryption where the key is only accessible to the app, and configure the app to require app secret proof for all API calls to Meta
2. If that option is not viable (i.e., if you cannot require app secret proof because it would block certain necessary API calls), then Meta will consider other controls that you have in place to limit the risk of unauthorized use of the access tokens compared to the risk of misuse of stored access tokens; provide as much detail as possible about the alternative protections you enforce

The evidence you submit must demonstrate that your plan:

1. Meets Meta's minimum requirements by detailing roles and responsibilities, detection, reaction and recovery, and post-incident review
2. Has been tested within the past 12 months

To meet Meta's requirements, submit the following:

• A copy of your incident response plan. It should be one or more documents containing the following information:

  • Roles and responsibilities
    Include description of each role, associated responsibilities, and redacted names of individuals assigned to each role
  • Detection
    Detail your processes for detecting security incidents, including tools used, monitoring frequency, etc.
  • Reaction and recovery
    Detail your post-detection response (e.g., assembling team, investigation), remediation, communication (both internal and external), and recovery plan
  • Post-incident review
    Conduct a meeting (after-action review, post-mortem, etc.) to discuss what was learned, what will change, and to communicate status and results
    
    

    If you do not have an incident response plan, there are many resources and templates available to help you get started. Check out Counteractive Security's Incident Response Plan template.

    
    

• Proof that you have tested the plan within the past 12 months. The form of proof can vary, but should include:

  • A description of the scenario you used to test the plan (e.g., a tabletop exercise in response to a ransomware attack)
  • The date of the most recent test
  • The role of each participant
  • An explanation for why any person named in the plan's roles and responsibilities did not participate in the test, if applicable

  Examples of acceptable evidence:

  Expand

  

  Expand

  

  Expand

  

• Unacceptable evidence would include statements that indicate:

  • You do not proactively test systems and processes
  • You have systems and processes in place, but no way to test them
  • It's been too long since you've tested your systems and processes (i.e., more than 12 months)
  

  Remember to remove or redact sensitive information from the evidence, including detailed vulnerability reproduction steps, before submitting.

MFA is required for the following tools and systems:

• Collaboration/communications tools, e.g., business email or Slack
• Code repository, e.g., GitHub or another tool used to track changes to the app/system's code or configuration

• If you process Platform Data server-side:

  • Software deployment tools used to deploy code into the cloud/server environment, e.g., Jenkins or another Continuous Integration/Continuous Deployment (CI/CD) tool
  • Administrative tools such as a portal or other access used to manage/monitor the cloud or server environment
  • Access to servers, including SSH, remote desktop, or similar tools used to remotely log in to servers running server-side

While you can use any MFA implementation, Meta recommends the use of an authenticator app or hardware (e.g., YubiKey) over codes sent by SMS.

This question requires both policy/procedure and implementation evidence. Your evidence must show that MFA is:

1. Enforced on the tools applicable to the environments outlined in the acceptance criteria (i.e., collaboration tools, code repository, cloud/server deployment, cloud/server administrative portal)
2. Enabled globally, i.e., for all users; do not just provide an example of a single account/device with MFA enabled. Show a configuration or rule set that demonstrates how you enforce MFA company-wide

Examples of acceptable evidence:

Expand

Expand

Expand

Expand

Unacceptable evidence would include statements that indicate that MFA is optional. For example:

• A statement indicating that employees can turn on MFA if they want
• A screenshot that indicates MFA is not required by your organization

MFA is recommended and preferred. But if you do not enforce MFA, one or more of the following alternative approaches may be sufficient to prevent account takeovers. Describe in detail whether your organization enforces:

• Strong password requirements

  Minimum password complexity, prohibiting dictionary words, and prohibiting passwords that are known to have been previously breached

• Authentication backoff

  Use of a tool that introduces increasingly long waiting periods in-between failed login attempts from the same source

• Automatic lockouts

  A mechanism to automatically block login to an account after a specific amount of failed login attempts (e.g., 10 attempts)

Your account maintenance processes and policies must prevent unauthorized use of accounts to gain access to Platform Data. A key component of this requirement is ensuring that access to resources and systems is revoked when it's no longer needed (e.g., an employee leaves the organization). To meet Meta's requirement, you must do all of the following:

1. Have a tool or process for managing accounts for tools, systems, or apps used to:

   • Communicate (e.g., business email or Slack)
   • Ship software (e.g., code repository)
   • Administer and operate any system that processes Platform Data
2. Regularly review access grants
3. Have a process in place for revoking access when it's no longer required AND no longer being used
4. Have a process to promptly revoke access to these tools when an employee leaves the organization

Meta does NOT require you to use any particular tool, or that you use a single consolidated tool to manage accounts across various access types.

This question requires both policy/procedure and implementation evidence.

• Your policy evidence should explain your account management practices in detail. You must demonstrate that you regularly review accounts and revoke access for employees that leave the company. Ideally, your documentation will include:
  • Procedures for creating accounts and granting permissions
  • Security requirements (e.g., minimum password complexity, account lockout policy, multi-factor authentication (MFA) policy, account reset procedures)
  • Process for revoking access after a period of inactivity, and when an employee leaves the organization
• You must also provide implementation evidence from at least one tool or process* in place to manage accounts that shows:
  • Employees that have departed the organization and had their access to these tools revoked, e.g., upload a reconciliation report comparing user accounts to the authoritative data of current employees
    • Note: You are not required to provide a screenshot from a tool; a spreadsheet is acceptable if that is the process your organization uses to manage accounts
  • Access that is not used for some time is revoked, e.g., upload a report that shows the last access date of an active account holder is within the past 90 days (if the max inactivity period is three months)

* This evidence should apply to one or more of the following:

• 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)

Remember to remove or redact sensitive information from the evidence, including detailed vulnerability reproduction steps, before submitting.

Examples of acceptable evidence:

Expand

Expand

You must have a defined, repeatable way of identifying available patches that resolve security vulnerabilities, prioritizing based on risk, and applying patches as an ongoing activity. The output of the identified vulnerability patches must show that there are no unresolved critical or high severity vulnerabilities. If any critical and high severity vulnerabilities identified pose no risk of unauthorized access to Meta Platform Data, please denote. This requirement applies to any of the following software components in place at your organization:

1. Libraries, SDKs, packages, app containers, and operating systems used in a cloud or server environment
2. Libraries, SDKs, and 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 laptop

Meta does NOT require you to use any particular tool for these activities. It is most likely that your organization uses different approaches for keeping different software up-to-date.

This question requires both policy/procedure and implementation evidence. Start by identifying the types of software in your environment that are in scope for the question. Include any libraries, SDKs, packages, virtual machine images, app containers, browsers, operating systems, and other applications used by employees and contributors.

Using a document or screenshot, upload evidence that demonstrates you do each of the following activities:

Implementation Evidence

You must provide a report of identified vulnerability patches via whichever tool you use to prove they keep your software up-to-date. The output must show that there are no unresolved critical or high severity vulnerabilities.

If any critical and high severity vulnerabilities identified pose no risk of unauthorized access to Meta Platform Data, make note of this in your evidence.

Policy or Procedure Evidence

Using a document or screenshot, upload evidence that demonstrates you do each of the following activities:

• Inventory in-scope software components

  Provide a list of in-scope libraries, packages, SDKs, containers, app servers, and operating systems (including on employee devices) that need to be patched on an ongoing basis

• Identify available software patches

  Show that you have a tool or process in place for identifying security patches for each of the items in your inventory

• Prioritize

  Demonstrate the tool or process you use to assign priority to software patches (e.g., Jira tickets, GitHub issues, tracking spreadsheet)

• Patch

  Demonstrate that after relevant patches have been identified and prioritized, they are rolled out into the various software components

Examples of acceptable evidence:

Expand

Expand

Within the environment that you store Platform Data, you must:

• Maintain audit logs that record key events (e.g., access to Platform Data, use of accounts with elevated permissions, changes to the audit log configuration)
• Consolidate the logs into a central, tamper-proof repository (i.e., the logs should be protected against alteration or deletion)

Meta does not require you to submit evidence in support of your answer.

If you process Platform Data server-side, then within that environment, you should:

• Keep an accurate data flow diagram that shows where Platform Data is stored, processed, and transmitted across networks
• Configure monitoring for transfers of Platform Data outside of the system (e.g., audit logs with an automated monitoring product)

If possible, configure the monitoring system to raise alerts that are reviewed promptly in case Platform Data is transferred unexpectedly.

Meta does not require you to submit evidence in support of your answer.

If you process Platform Data server-side, you should:

• Have a tool that can ingest log files and other events, establish rules that trigger alerts, and have a mechanism to notify your team (e.g., on-call InfoSec investigator)
• Actively ingest relevant signals into the tool (e.g., web access logs, authentication attempts, actions taken by users with elevated privileges)
• Continuously refine the rules to find an ideal balance (i.e., avoiding false positives while paying attention to events that warrant investigation)

Meta does not require you to submit evidence in support of your answer.