Minimum Security Requirements for Third-Parties

Subject to change as set forth below. Save a copy of this version as needed for your internal records.

1. Scope and Purpose.

These Minimum Security Requirements for Third-Parties (“Security Requirements”) establish these baseline protection standards Magic Leap, Inc. and its affiliates (“Magic Leap”) mandates for any vendor, contractor or supplier (“Third-Party”) handling or accessing any Magic Leap Data. “Magic Leap Data” means all Magic Leap assets, including personal information, intellectual property, financial information and any other information or documents in Magic Leap’s possession or control. These standards are based on industry-recognized security and governance frameworks. These Security Requirements do not limit any of Third-Party’s other contractual or legal obligations. To the extent there is a conflict between these Security Requirements and other agreements between Third-Party and Magic Leap, Third-Party will comply with the more restrictive requirements that better protect Magic Leap Data.

These Security Requirements apply to all Third-Party personnel (“Personnel”) defined as any employee, contractor, subcontractor, or agent of the Third-Party who: (a) accesses Magic Leap Data; (b) has logical or physical access to Magic Leap networks; or (c) provides services impacting Magic Leap’s security environment (e.g., developers, admins, and consultants). The Third-Party is responsible for ensuring all such Personnel comply with these Security Requirements.

2. Applicability

These Security Requirements apply to:

• 2.1. Systems & Networks: All Third-Party information technology systems and networks that integrate with Magic Leap infrastructure or are utilized to process, store, or transmit Magic Leap Data.
• 2.2. Data Integrity: Magic Leap Data in any form, including electronic or physical.

3. Compliance

The Third-Party shall successfully complete:

• 3.1. Risk Assessment: Third-Party has successfully completed the Magic Leap vendor risk assessment process.
• 3.2. Maintenance of Controls: Third-Party shall maintain all safeguards, technical controls, and organizational measures identified during said assessment.
• 3.3. Remediation: Third-Party shall take any additional security steps or corrective actions required by Magic Leap to address emerging threats or identified vulnerabilities.

4. Policy and Procedures

• 4.1. Lifecycle Management: Third-Party shall maintain a formal process for the creation, maintenance, review, and communication of security policies. This includes standards for application/infrastructure development, data storage, incident management, and IT operations.
• 4.2. Baseline Configurations: Third-Party shall implement documented baseline security configurations, reviewed annually and communicated to all relevant personnel.
• 4.3. Information Security Management System (ISMS): Third-Party shall maintain an ISMS and security policy approved by Third-Party’s senior management. This system must define at a minimum: (a) segregated security roles, (b) policy objectives, (c) personnel responsibilities, and (d) regulatory compliance requirements, including privacy and data security.
• 4.4. Change Policy: Third-Party shall maintain an annually reviewed change management policy covering all layers (application, database, OS, virtualization, and microservices) that defines change types, approvals, and testing.
• 4.5. Cryptographic Key Management: Third-Party shall maintain procedures for strong key generation, secure distribution, encrypted storage, periodic rotation (cryptoperiods), and the decommissioning of compromised keys.

5. Information Asset Management

• 5.1. Inventory and Lifecycle: Third-Party shall implement documented policies for identifying, classifying, and managing information assets from procurement through to secure disposal.

6. Business Continuity and Disaster Recovery (“BCDR”)

• 6.1. Strategy and Review: Third-Party shall maintain BCDR policies that are documented, approved, and reviewed on an annual basis.
• 6.2. Critical System Identification: Third-Party shall identify and document all critical systems and maintain procedures to ensure operational continuity during adverse events.
• 6.3. Backup Protocols: Third-Party shall maintain (a) automated, scheduled backups; (b) error alerting for failed backup jobs with timely remediation; and (c) periodic testing of restoration processes to ensure recovery from system failure or data corruption.

7. Change Management

• 7.1. Production Controls: All system changes made by Third-Party must follow a formal process for review, approval, and testing before being deployed to the production environment.
• 7.2. Emergency Changes: Emergency changes must be requested, approved, and documented by Third-Party in accordance with the change management policy established by Third-Party.

8. Human Resource Security

• 8.1. Personnel Screening: To the extent permitted by law, Third-Party shall perform criminal background checks on personnel before allowing them to handle Magic Leap Data or access Magic Leap networks/facilities. Personnel with certain felony or repeat misdemeanor convictions involving violence or harassment are prohibited from providing services in non-public Magic Leap areas.
• 8.2. Security Training: All Third-Party Personnel must complete privacy and information security training prior to handling or accessing Magic Leap Data, with regular refresher training required thereafter.
• 8.3. Confidentiality and Discipline: Personnel are required to keep Magic Leap Data confidential. Third-Party shall provide managerial oversight and maintain a formal disciplinary process (including termination) for security policy violations.

9. Information Security

• 9.1. Infrastructure Security: Third-Party shall ensure the security of its networks, applications, databases, and platforms.
• 9.2. Segregation of Duties: Third-Party shall ensure conflicting activities are segregated, specifically:
  
  • 9.2.1. Separating development and production environments.
  • 9.2.2. Separating application administration from access rights administration.
  • 9.2.3. Separating database administration from application and security administration.
  • 9.2.4. Separating the approval of access rights from the granting of those rights.
• 9.3. Risk Assessments: Third-Party shall perform annual risk assessments on critical systems and networks, adjusting configurations based on findings.
• 9.4. Data Classification: Third-Party shall maintain policies  that ensure all data is secured according to its sensitivity level.
• 9.5. Access Control & Termination: Access requests must be reviewed by Third-Party management . Third-Party shall implement system alerts for personnel status changes (termination/transfer) and ensure access is removed immediately when no longer required for job responsibilities.
• 9.6. Entitlement Reviews: Third-Party shall regularly review user and system accounts for accuracy and necessity.
• 9.7. Perimeter & Cloud Security: Third-Party shall maintain industry-standard perimeter controls and adhere to cloud provider best practices. If Magic Leap provides specific configuration requirements for perimeter controls and cloud controls, then Third-party shall comply with these specific requirements.
• 9.8. Vulnerability Management: Third-Party shall perform annual penetration testing and quarterly vulnerability scans. Up-to-date antivirus and anti-malware software must be maintained.
• 9.9. Physical Security: Third-Party’s facilities handling Magic Leap Data shall utilize electronic access controls, security monitoring, and environmental protections (heat/smoke detection).
• 9.10. Encryption: Third-Party shall protect Magic Leap Data by industry-standard encryption (NIST-compliant) both at rest and in transit.
• 9.11. Logging: Third-Party must log security activity  at the OS, application, and database levels, with logs retained for at least 12 months.
• 9.12. Logical Segregation: Third-Party shall ensure strict segregation of Magic Leap Data from non-Magic Leap Data to prevent commingling.

10. Project Management

• 10.1. Secure Systems Development Lifecycle (“SDLC”): Third-Party shall utilize a SDLC which follows a documented, formal process for developing systems that integrate security at every stage.
• 10.2. Development Standards: Third-Party shall follow industry standards (e.g., OWASP Top Ten, ISO 27002). Magic Leap Data must not be used in test environments.
• 10.3. Quality Assurance: Third-Party shall ensure that all services and deliverables  undergo quality assurance, user acceptance testing, and secure code reviews.

11. Artificial Intelligence (AI) Security and Governance

• 11.1. Transparency & Disclosure: Third-Party must disclose all AI tools (e.g., Gemini, ChatGPT, Claude) used in the performance or engagement with Magic Leap. 
• 11.2. Data Sovereignty: Third-Party shall not use Magic Leap Data (including telemetry, source code, or documentation) to train, fine-tune, or improve any proprietary or third-party AI models.
• 11.3. Technical Defense: Third-Party must implement industry-standard controls to mitigate AI-specific threats (e.g., OWASP Top 10 for LLMs), specifically preventing Prompt Injection and ensuring Insecure Output Handling sanitization.
• 11.4. Human-in-the-Loop (HITL): Any and all AI-generated deliverables must undergo documented human review by a qualified human professional of the Third-Party before submission. 
• 11.5. Verification: Magic Leap reserves the right to audit Third-Party’s AI configurations and "opt-out" settings to ensure compliance with training prohibitions.

12. Incident Response

• 12.1. Response Plan: Third-Party shall maintain a policy for incident detection, containment, recovery, escalation, and notification.
• 12.2. Testing: Third-Party must test periodically the incident response activities, including coordination with its relevant subcontractors or cloud providers.

13. Subcontracting and Flow-Down

• 13.1. No Subcontracting: Third Party shall not subcontract any services without Magic Leap’s prior written consent in each instance.
• 13.2. Flow-Down: Approved subcontractors must be bound by written terms at least as restrictive as these Security Requirements, specifically regarding security, AI governance, and audit rights.
• 13.3. Liability: Third- Party remains primarily liable for all acts or omissions of its subcontractors as if performed by the Third-Party.

14. Updates

• Magic Leap may make commercially reasonable updates to these Security Requirements  from time to time, which will become effective 30 days after the “Last updated” date of these Security Requirements. Third-Party agrees to be bound by the updated Security Requirements once the updates come into effect.

The provisions in these Security Requirements are supplementary to any contractual agreement between Magic Leap and the Third-Party and shall not derogate from any obligation that the Third-Party is subject to under applicable law (including privacy and data protection laws and regulations).