*This content was last updated in March 2026, and represents the status quo
as of the time it was written. Google's security policies and systems may change
going forward, as we continually improve protection for our customers.*

## Introduction

[Google Maps Platform](https://mapsplatform.google.com/) provides APIs and SDKs for customers and
partners to develop web and mobile applications using Google's geospatial
technology. Google Maps Platform offers over 50+ APIs and SDK for customers
across multiple industries. As a customer in industry, you must often meet
security, data usage, and regulatory requirements when building your solutions.
This includes ensuring your third-party technology meets those same
requirements.

This document provides a high-level summary of the people, process, and
technology controls offered by Google Maps Platform, along with describing the
benefits of using the platform. First, it's important to understand the two
primary technology pillars beneath Google Maps Platform:

- **Google-provided technologies, data centers, and infrastructure**. Google Maps Platform operates entirely on Google-provided data centers and infrastructure. From this basis it applies internal and 3rd-party audits to the security controls it inherits from Google to validate that Google Maps Platform correctly implements the security, operational, and technical controls described in this paper.
- **Google Maps Platform technology**. In addition to the inherited controls, Google Maps Platform provides additional security, privacy, data, and operational controls for Google's product suites.

This document summarizes Google Maps Platform's security processes and controls,
grouped as follows:

- Focus on security and privacy at all levels of Google's organization
- Technical infrastructure and hardware security
- Operational security
- Key security controls
- Client-side security, both web and mobile
- Current certifications and audits in Google Maps Platform
- Supported legal frameworks, globally

Potential customers can reach out to their [Google sales
representative](https://mapsplatform.google.com/contact-us/) for additional information.

## Google's security and privacy-focused culture

Security drives the organizational structure, culture, training priorities, and
hiring processes across Google. It shapes the design of Google data centers and
the technology they provide. Security underpins Google's everyday operations,
including disaster planning and threat management. Google prioritizes security
in how it handles data, account controls, compliance audits, and industry
certifications. Google designs its services to deliver better security than many
on-premise alternatives that rely on multiple vendors and multiple platforms
where security is often an unconnected process. You benefit from Google's
integrated security programs and controls when you leverage Google Maps Platform
products for your business. Google Maps Platform makes security a priority in
its operations---operations that serve over a billion users across the world.

Together, Google and Google Maps Platform provide multiple layers of security
throughout the company and organization:

- Google dedicated security team
- Google Maps Platform product security team
- Active involvement with the global security research community
- Google Maps Platform privacy team
- Google employee security and privacy training
- Internal audit and compliance specialists

### Dedicated security teams at Google

Google provides dedicated security teams across the company and within product
areas.

The **Google-wide security teams** support multiple product areas at Google,
including Google Maps Platform. The security team includes some of the world's
foremost experts in information security, application security, cryptography,
and network security. Their activities include the following:

- **Develops, reviews, and implements security processes**. This includes reviewing security plans for Google networks and providing project-specific consulting to product and engineering teams across Google. For example, cryptography specialists review product launches that implement cryptography as part of the offering.
- **Actively manages security threats**. Using both commercial and custom tools, the team monitors ongoing threats and suspicious activity on Google networks.
- **Performs routine audits and evaluations**, which can involve engaging outside experts to conduct security assessments.
- **Publishes security articles to the wider community** . Google maintains a [security blog](https://blog.google/technology/safety-security/) and a [YouTube Series](https://www.youtube.com/playlist?list=PL590L5WQmH8dsxxz7ooJAgmijwOz0lh2H) highlighting several of the specific [Security Teams](https://blog.google/technology/safety-security/meet-the-hackers-keeping-you-safe-online/) and their accomplishments.

**The Google Maps Platform security team** collaborates with the Google-wide
security team, working more closely with product development and SRE to oversee
security implementation. Specifically, this team manages the following:

- Google Maps Platform's [Disaster Resilience Testing (DiRT)](https://developers.google.com/maps/security/compliance/security-compliance.md.txt#disaster-recovery), which tests the business continuity and failover of Google Maps Platform products, runs on Google's highly available infrastructure.
- Third party [penetration testing](https://developers.google.com/maps/security/compliance/services-in-scope.md.txt). Google Maps Platform products are penetration tested on at least an annual basis to enhance Google's security posture and provide you with independent security assurance.

### Collaboration with the security research community

Google has long enjoyed a close relationship with the security research
community, and Google greatly values their help with identifying potential
vulnerabilities in Google Maps Platform and other Google products. Our security
teams take part in research and outreach activities to benefit the online
community. For example, we run [Project Zero](https://googleprojectzero.blogspot.com/), which is a team
of security researchers dedicated to researching zero-day vulnerabilities. Some
examples of this research are the discovery of the [Spectre](https://spectreattack.com/spectre.pdf)
exploit, the [Meltdown](https://meltdownattack.com/meltdown.pdf) exploit, the [POODLE SSL 3.0 exploit](http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html),
and [cipher suite weaknesses](http://googleonlinesecurity.blogspot.com/2013/11/a-roster-of-tls-cipher-suites-weaknesses.html).

Google's security engineers and researchers actively participate and publish in
the academic security community and the privacy research community. Security
related publications can be found on Google's [Google Research site](https://research.google/pubs/).
Google's security teams have published an in-depth account of their practices
and experience in the [Building Secure and Reliable Systems](https://sre.google/books/building-secure-reliable-systems/) book.

Our [Vulnerability Reward Program](https://www.google.com/about/appsecurity/reward-program/) offers rewards in the
tens of thousands of dollars for each confirmed vulnerability. The program
encourages researchers to report design and implementation issues that might
put customer data at risk. In 2024, Google awarded researchers over $12
million in prize money, and over $65 million since the Vulnerability Reward Program began in 2010. To help improve the security of open-source code, the
Vulnerability Program also provides a [variety of initiatives](https://bughunters.google.com/open-source-security) to
researchers For more information about this program, including the rewards
Google gave, see [Bug Hunters Key Stats](https://bughunters.google.com/about/key-stats).

Our world-class cryptographers participate in industry-leading cryptography
projects. For example, we designed the [Secure AI Framework (SAIF)](https://blog.google/technology/safety-security/introducing-googles-secure-ai-framework/)
to help secure AI systems. In addition, to protect TLS connections against quantum
computer attacks, we developed the [combined elliptic-curve and post-quantum
(CECPQ2) algorithm](https://www.chromium.org/cecpq2/). Our cryptographers developed [Tink](https://developers.google.com/tink),which is an open source library of cryptographic APIs. We also use
Tink in our internal products and services.

For more information about how you can report security issues, see [How Google
handles security vulnerabilities](https://www.google.com/about/appsecurity/).

### Google Maps Platform's dedicated privacy team

The dedicated privacy team operates separately from product development and
security organizations. It supports internal privacy initiatives to improve all
parts of privacy: critical processes, internal tools, infrastructure, and
product development. The privacy team performs the following:

- Ensures that every privacy-impacting GMP product launch incorporates strong privacy standards and Privacy by Design through design documentation assessment and launch review
- Consults with GMP product teams at any stage of development to advise on Google privacy policy and infrastructure, privacy design, Privacy Enhancing Technologies and controls, and privacy risk assessment and mitigation.
- After product launch, the privacy team oversees processes that verify appropriate data collection and use.
- Conducts research on privacy best practices, contributes to international privacy standards working groups, and participates in academic privacy summits and conferences. .

### Google employee security and privacy training

All Google employees undergo security and privacy training as part of the orientation process, and they receive ongoing security and privacy training throughout their Google careers. During orientation, new employees agree to our [Code of Conduct](https://abc.xyz/investor/other/google-code-of-conduct/), which highlights Google's commitment to keeping customer information safe and secure.

Depending on their job role, employees might be required to take additional training on specific aspects of security. For example, the information security team instructs new engineers on secure coding practices, product design, and automated vulnerability testing tools. Engineers attend regular security briefings and receive security newsletters that cover new threats, attack patterns, mitigation techniques, and more.

Security and privacy are an ever-changing area, and we recognize that dedicated employee engagement is a key means of raising awareness. We host regular internal conferences that are open to all employees to raise awareness and drive innovation in security and data privacy. We host events across global offices to raise awareness of security and privacy in software development, data handling, and policy enforcement.

### Internal audit and compliance specialists

Google Maps Platform has a dedicated internal audit team that reviews Google
products' compliance with security laws and regulations around the world. As new
auditing standards are created and existing standards are updated, the internal
audit team determines what controls, processes, and systems are needed to help
meet those standards. This team supports independent audits and assessments by
third parties. For more information, see [Security Certifications \& Audits](https://developers.google.com/maps/security/compliance/security-compliance.md.txt#audits)
section later in this document.

## Platform built with security at its core

Google designs its servers, proprietary operating systems, and geographically
distributed data centers using the principle of defense in depth. Google Maps
Platform runs on a technical infrastructure designed and built to operate
securely. We've created an IT infrastructure that is more secure and easier to
manage than more traditional on-premises or hosted solutions.

### State-of-the-art data centers

Google's focus on security and protection of data is among [Google's primary
design criteria](https://cloud.google.com/docs/security/infrastructure/design). The physical security in Google [data
centers](https://www.google.com/about/datacenters/)
is a layered security model. Physical security includes safeguards like
custom-designed electronic access cards, alarms, vehicle access barriers,
perimeter fencing, metal detectors, and biometrics. In addition, to detect and
track intruders, Google uses security measures such as laser beam intrusion
detection and 24/7 monitoring by high-resolution interior and exterior cameras.
Access logs, activity records, and camera footage are available in case an
incident occurs. Experienced security guards, who have undergone rigorous
background checks and training, routinely patrol Google's data centers. As you
get closer to the data center floor, security measures also increase. Access to
the data center floor is only possible through a security corridor that
implements multi-factor access control using security badges and biometrics.
Only approved employees with specific roles may enter. Less than one percent of
Google employees will ever set foot in one of Google's data centers.

Google operates data centers globally and to maximize the speed and reliability
of its services. Its infrastructure is generally set up to serve traffic from
the data center that is the closest to where the traffic originates. Therefore
the precise location of Google Maps Platform data may vary depending on where
such traffic originates, and this data may be handled by servers located in the
EEA and UK or transferred to third countries. Google customers' offerings where
Google Maps Platform products are implemented are generally available globally
and often attract a global audience. The technical infrastructure that supports
these products is deployed globally to reduce latency and ensure redundancy of
systems. Google Maps Platform uses a subset of Google Global Data Center Network
listed below for reference:

![World map showing data center locations as blue
dots](https://developers.google.com/static/maps/images/data-center-map.png)

North \& South America

- [The United States](https://www.google.com/about/datacenters/locations/)
- [Chile](https://www.google.com/about/datacenters/locations/quilicura/)

Europe

- [Belgium](https://www.google.com/about/datacenters/locations/st-ghislain/)
- [Finland](https://www.google.com/about/datacenters/locations/hamina/)
- [The Netherlands](https://www.google.com/about/datacenters/locations/eemshaven/)

Asia

- [Taiwan](https://www.google.com/about/datacenters/locations/changhua-county/)
- [Singapore](https://www.google.com/about/datacenters/locations/singapore/)

### Powering Google data centers

To keep things running 24/7 and provide uninterrupted services, Google data
centers have redundant power systems and environmental controls. Every critical
component has a primary and alternate power source, each with equal power.
Backup generators can provide enough emergency electrical power to run each data
center at full capacity. Cooling systems maintain a constant operating
temperature for servers and other hardware, which reduces the risk of service
outages while [minimizing environmental impact](https://www.google.com/about/datacenters/efficiency/). Fire detection
and suppression equipment helps prevent hardware damage. Heat detectors, fire
detectors, and smoke detectors trigger audible and visible alarms at security
operations consoles and at remote monitoring desks.

Google is the first major internet services company to get external
certification of its high environmental, workplace safety, and energy management
standards throughout Google data centers. For example, to demonstrate Google's
commitment to energy management practices, Google obtained voluntary [ISO
50001](https://mapsplatform.google.com/resources/trust-center/iso-50001-2018/) certifications for its data centers in Europe.

### Custom server hardware and software

Google data centers have purpose-built servers and network equipment, some of
which Google designs. While Google's servers are customized to maximize
performance, cooling, and power efficiency, they are also designed to help
protect against physical intrusion attacks. Unlike most commercially available
hardware, Google's servers don't include unnecessary components such as video
cards, chipsets, or peripheral connectors, all of which can introduce
vulnerabilities. Google vets component vendors and chooses components with care,
working with vendors to audit and validate the security properties that are
provided by the components. Google designs custom chips, such as
[Titan](https://cloud.google.com/blog/products/identity-security/titan-in-depth-security-in-plaintext), that help us securely identify and authenticate
legitimate Google devices at the hardware level, including the code that these
devices use to boot up.

Server resources are dynamically allocated. This gives us flexibility for growth
and lets us adapt quickly and efficiently to customer demand by adding or
reallocating resources. This homogeneous environment is maintained by
proprietary software that continually monitors systems for binary-level
modifications. Google's automated, self-healing mechanisms are designed to
enable us to monitor and remediate destabilizing events, receive notifications
about incidents, and slow down potential compromises on the network.

### Secure service deployment

Google services are the application binaries that Google developers write and
run on Google's infrastructure. To handle the required scale of the workload,
thousands of machines might be running binaries of the same service. A cluster
orchestration service, called [Borg](https://research.google/pubs/large-scale-cluster-management-at-google-with-borg/), controls the services that
are running directly on the infrastructure.

The infrastructure does not assume any trust between the services that are
running on the infrastructure. This trust model is referred to as a zero-trust
security model. A zero-trust security model means that no devices or users are
trusted by default, whether they are inside or outside of the network.

Because the infrastructure is designed to be multi-tenant, data from Google's
customers (consumers, businesses, and even Google's own data) is distributed
across shared infrastructure. This infrastructure is composed of tens of
thousands of homogeneous machines. The infrastructure does not segregate
customer data onto a single machine or set of machines

### Hardware tracking and disposal

Google meticulously tracks the location and status of all equipment within its
data centers using barcodes and asset tags. Google deploys metal detectors and
video surveillance to help make sure that no equipment leaves the data center
floor without authorization. If a component fails to pass a performance test at
any point during its lifecycle, it's removed from inventory and retired.

Google storage devices, including hard drives, solid-state drives, and
non-volatile dual in-line memory modules (DIMM), use technologies like full disk
encryption (FDE) and drive locking to protect data at rest. When a storage
device is retired, authorized individuals verify that the disk is erased by
writing zeros to the drive. They also perform a multiple-step verification
process to ensure the drive contains no data. If a drive cannot be erased for
any reason, it's physically destroyed. Physical destruction is done by using a
shredder that breaks the drive into small pieces, which are then recycled at a
secure facility. Each data center adheres to a strict disposal policy and any
variances are immediately addressed.

### Security benefits of Google's global network

In other geospatial cloud and on-premises solutions, data travels between
devices across the public internet in paths known as *hops*. The number of hops
depends on the optimal route between the customer's ISP and the data center.
Each additional hop introduces a new opportunity for data to be attacked or
intercepted. Because Google's global network is linked to most ISPs in the
world, Google's network limits hops across the public internet, and therefore
helps limit access to that data by bad actors.

Google's network uses multiple layers of defense---defense in depth---to help
protect the network against external attacks. Only authorized services and
protocols that meet Google's security requirements are allowed to traverse it;
anything else is automatically dropped. To enforce network segregation, Google
uses firewalls and access control lists. All traffic is routed through Google
Front End (GFE) servers to help detect and stop malicious requests and
distributed denial-of-service (DDoS) attacks. Logs are routinely examined to
reveal any exploitation of programming errors. Access to networked devices is
restricted to only authorized employees.

Google's global infrastructure allows us to run [Project
Shield](https://projectshield.google/), which provides free, unlimited protection to websites
that are vulnerable to DDoS attacks that are used to censor information. Project
Shield is available for news websites, human rights websites, and
election-monitoring websites.

#### Low latency and highly available solutions

Google's IP data network consists of its own fiber, of publicly available fiber,
and of undersea cables. This network allows us to deliver highly available and
low-latency services across the globe.

Google designs the components of its platform to be highly redundant. This
redundancy applies to Google's server design, to how Google stores data, to
network and internet connectivity, and to the software services themselves. This
"redundancy of everything" includes exception handling and creates a solution
that is not dependent on a single server, data center, or network connection.

Google data centers are geographically distributed to minimize the effects of
regional disruptions on global products, such as when natural disasters or local
outages occur. If hardware, software, or a network fails, platform services and
control planes are automatically and swiftly shifted from one facility to
another so that platform services can continue without interruption.

Google's highly redundant infrastructure also helps you protect your business
from data loss. Google's systems are designed to minimize downtime or
maintenance windows for when we need to service or upgrade our platform.

## Operational security

Security is integral to Google's operations, not an afterthought. This section
describes Google's vulnerability management programs, malware prevention
program, security monitoring, and incident management programs.

### Vulnerability management

Google's internal vulnerability management process actively scans for security
threats across all technology stacks. This process uses a combination of
commercial, open source, and purpose-built in-house tools, and includes the
following:

- Quality assurance processes
- Software security reviews
- Intensive automated and manual penetration efforts, including extensive Red Team exercises
- Recurring [external penetration testing](https://developers.google.com/maps/security/compliance/services-in-scope.md.txt) for Google Maps Platform products
- Recurring [external audits](https://developers.google.com/maps/security/compliance/security-compliance.md.txt#audits)

The vulnerability management organization and its partners are responsible for
tracking and following up on vulnerabilities. Because security improves only
after issues are fully addressed, automation pipelines continuously reassess the
state of a patch deployment to mitigate vulnerabilities and flag incorrect or partial deployment.

To help improve detection capabilities, the vulnerability management organization focuses on high-quality indicators that separate noise from signals that indicate real threats. The organization also fosters interaction with the industry and with the open-source community. For example, they run a [Patch Reward Program](https://security.googleblog.com/2021/09/announcing-new-patch-reward-program-for.html) for the [Tsunami](https://github.com/google/tsunami-security-scanner) network security scanner, which rewards developers who create open-source detectors for vulnerabilities.

### Malware prevention

Google maintains malware protections for our core products (like Gmail, Google Drive, Google Chrome, YouTube, Google Ads, and Google Search) that use a variety of malware detection techniques. To discover malware files proactively, we use web crawling, file detonation, custom static detection, dynamic detection, and machine-learning detection. We also use multiple antivirus engines.

To help protect our employees, we use the built-in advanced security capabilities of Chrome Enterprise Premium and the Enhanced Safe Browsing feature in Google Chrome. These capabilities enable proactive detection of phishing and malware sites as our employees browse the web. We also enable the most rigorous security settings that are available in Google Workspace, such as Gmail Security Sandbox, to proactively scan suspicious attachments. Logs from these capabilities feed into our security monitoring systems, as described in the following section.

### Security monitoring

Google's security monitoring program is focused on information that's gathered
from internal network traffic, from employee actions on systems, and from
outside knowledge of vulnerabilities. A core Google principle is to aggregate
and store all security telemetry data in one location for unified security
analysis.

At many points across Google's global network, internal traffic is inspected for
suspicious behavior, such as the presence of traffic that might indicate botnet
connections. Google uses a combination of open source and commercial tools to
capture and parse traffic so that Google can perform this analysis. A
proprietary correlation system built on top of Google's technology also supports
this analysis. Google supplements network analysis by examining system logs to
identify unusual behavior, such as attempts to access customer data.

The [Threat Analysis Group](https://blog.google/threat-analysis-group/) at Google monitors threat actors and
the evolution of their tactics and techniques. Google security engineers review
inbound security reports and monitor public mailing lists, blog posts, and
wikis. Automated network analysis and automated analysis of system logs helps
determine when an unknown threat might exist. If the automated processes detect
an issue, it's escalated to Google's security staff.

### Intrusion detection

Google uses sophisticated data processing pipelines to integrate host-based
signals on individual devices, network-based signals from various monitoring
points in the infrastructure, and signals from infrastructure services. Rules
and machine intelligence built on top of these pipelines give operational
security engineers warnings of possible incidents. Google's investigation and
incident-response teams triage, investigate, and respond to these potential
incidents 24 hours a day, 365 days a year. Google conducts Red Team exercises in
addition to external penetration testing to measure and improve the
effectiveness of Google's detection and response mechanisms.

### Incident management

Google has a rigorous incident management process for security events that might
affect the confidentiality, integrity, or availability of systems or data.
Google's security incident management program is structured around the NIST
guidance on handling incidents ([NIST SP 800--61](https://csrc.nist.gov/pubs/sp/800/61/r2/final)). Google provides training
for key staff members in forensics and in handling evidence in preparation for
an event, including the use of third-party and proprietary tools.

Google tests incident response plans for key areas. These tests consider various
scenarios, including insider threats and software vulnerabilities. To help
ensure the swift resolution of security incidents, the Google security team is
available 24/7 to all employees.

For more information about our data incident response process, see [Google Maps Platform Incident Management](https://developers.google.com/maps/incident-management.md.txt).

### Software development practices

Google uses source control protections and two-party reviews to proactively
limit the introduction of vulnerabilities. Google also provides libraries that
prevent developers from introducing certain classes of security bugs. For
example, Google has libraries and frameworks designed to eliminate XSS
vulnerabilities in SDKs. Google also has automated tools for detecting security
bugs, such as fuzzers, static analysis tools, and web security scanners.

#### Source code protections

Google's source code is stored in repositories with built-in source integrity
and governance, which makes it possible to audit both current and past versions
of the service. The infrastructure requires that a service's binaries be built
from specific source code after it is reviewed, checked in, and tested. [Binary
Authorization for Borg (BAB)](https://cloud.google.com/docs/security/binary-authorization-for-borg) is an internal enforcement check
that occurs when a service is deployed. BAB does the following:

- Ensures that the production software and configuration deployed at Google is reviewed and authorized, particularly when that code can access user data
- Ensures code and configuration deployments meet certain minimum standards
- Limits the ability of an insider or adversary to make malicious modifications to source code and also provides a forensic trail from a service back to its source

### Reducing Insider Risk

Google limits and actively monitors the activities of employees who have been
granted administrative access to the infrastructure. Google continually works to
eliminate the need for privileged access for particular tasks by using
automation that can accomplish the same tasks in a safe and controlled way. For
example, Google requires two-party approvals for some actions, and Google uses
limited APIs that allow debugging without exposing sensitive information.

Google employee access to end-user information is logged through low-level
infrastructure hooks. Google's security team monitors access patterns and
investigates unusual events.

### Disaster Recovery Testing - DiRT

Google Maps Platform runs annual, company-wide, multi-day Disaster Recovery
Testing events (DiRT) to ensure that Google Maps Platform's services and
internal business operations continue to run during a disaster. DiRT was
developed to find vulnerabilities in critical systems by intentionally causing
failures, and to fix those vulnerabilities before failures happen in an
uncontrolled manner. DiRT tests Google's technical robustness by breaking live
systems and tests Google's operational resilience by explicitly preventing
critical personnel, area experts, and leaders from participating. All generally
available services are required to have ongoing, active DiRT testing and
validation of their resilience and availability.

To prepare for a DiRT exercise, Google employs a consistent [set of
rules](https://cloud.google.com/blog/products/management-tools/shrinking-the-time-to-mitigate-production-incidents) around prioritization, communication protocols, impact expectations, and test design requirements,
including pre-reviewed and approved rollback plans. DiRT exercises and scenarios
not only force technical failures in the service itself, but also can include
designed failures in process, availability of key personnel, supporting systems,
communications, and physical access. DiRT validates that the processes in place
actually work in practice. It also ensures that teams are pre-trained and have
experience they can draw upon during actual outages, disruptions, and disasters
man-made or natural.

## Key security controls

This section describes the main security controls that Google Maps Platform
implements to protect its platform.

### Encryption

[Encryption](https://mapsplatform.google.com/resources/trust-center/fips-140-2/) adds a layer of defense for protecting data.
Encryption ensures that if an attacker gets access to data, the attacker cannot
read the data without also having access to the encryption keys. Even if an
attacker gets access to data (for example, by accessing the wire connection
between data centers or by stealing a storage device), they won't be able to
understand or decrypt it.

Encryption provides an important mechanism in how Google helps protect the
privacy of data. It allows systems to manipulate data---for example, for
backup---and engineers to support Google's infrastructure, without providing
access to content for those systems or employees.

#### Encryption at rest

Encryption "at rest" in this section means encryption used to protect data that
is stored on a disk (including solid-state drives) or backup media. Data is
encrypted at the storage level, generally using AES256 (Advanced Encryption
Standard). Data is often encrypted at multiple levels in Google's production
storage stack in data centers, including at the hardware level, without
requiring any action by Google customers.

Using multiple layers of encryption adds redundant data protection and allows Google to choose the optimal approach
based on application requirements. Google uses common cryptographic libraries
which incorporate [Google's FIPS 140-2 validated module](https://mapsplatform.google.com/resources/trust-center/fips-140-2/) to
implement encryption consistently across products. Consistent use of common
libraries means that only a small team of cryptographers needs to implement and
maintain this tightly controlled and reviewed code.

#### Protecting data in transit

Data can be vulnerable to unauthorized access as it travels across the internet.
Google Maps Platform supports strong encryption in transit between customer
devices and networks, and Google's Google Front End (GFE) servers. Google
recommends that customers/developers use Google's strongest supported cipher
suite (TLS 1.3) when creating applications as a best practice. Some customers
have use cases that require older cipher suites for compatibility reasons, so
Google Maps Platform supports these weaker standards, but does not recommend
using them whenever possible. Google Cloud also offers you additional transport
encryption options, including Cloud VPN for establishing virtual private
networks using IPsec for Google Maps Platform products.

#### Protecting data in transit between Google data centers

Application Layer Transport Security (ALTS) ensures that the integrity of Google
traffic is protected and encrypted as needed. After a [handshake
protocol](https://cloud.google.com/docs/security/encryption-in-transit/application-layer-transport-security) between the client and the server is complete and the
client and the server negotiate the necessary shared cryptographic secrets for
encrypting and authenticating network traffic, ALTS secures RPC (Remote
Procedure Call) traffic by forcing integrity, using the negotiated shared
secrets. Google supports multiple protocols for integrity guarantees, such as
AES-GMAC (Advanced Encryption Standard), with 128-bit keys. Whenever traffic
leaves a physical boundary controlled by or on behalf of Google, for example in
transit over WAN (Wide Area Network) between data centers, all protocols are
upgraded automatically to provide encryption and integrity guarantees.

### Google Maps Platform Service Availability

Some Google Maps Platform services might not be available across all
geographies. Some service disruptions are temporary (due to an unanticipated
event, such as a network outage), but other service limitations are permanent
due to government-imposed restrictions. Google's comprehensive [Transparency
Report](https://transparencyreport.google.com/) and [status dashboard](https://status.cloud.google.com/maps-platform/) show recent and
ongoing disruptions of traffic to Google Maps Platform services. Google provides
this data to help you analyze and understand Google's uptime information.

## Client-side security

Security is a shared responsibility between a Cloud Service Provider and the
customer/partner implementing Google Maps Platform products. This section
details the customer/partner responsibilities that should be considered when
architecting a Google Maps Platform solution.

### JavaScript APIs

#### Secure Sites

Maps JavaScript API publishes a [set of recommendations](https://developers.google.com/maps/documentation/javascript/content-security-policy.md.txt) that allow a
customer to fine tune their site Content Security Policy (CSP) to avoid
vulnerabilities like cross-site scripting, clickjacking, and data injection
attacks. The JavaScript API supports two forms of CSP: strict CSP using nonces
and allowlist CSP.

#### Secure JavaScript

The JavaScript is regularly scanned for known security anti-patterns, and
problems are quickly remediated. The JavaScript API is released on a weekly
cadence or on demand, should any problems arise.

### Mobile Application Security (MAS)

Mobile Application Security (MAS) is an open, agile, crowd-sourced effort, made
of the contributions of dozens of authors and reviewers from all over the world.
The OWASP Mobile Application Security (MAS) flagship project provides a security
standard for mobile apps (OWASP MASVS) and a comprehensive testing guide (OWASP
MASTG) that covers the processes, techniques, and tools used during a mobile app
security test, as well as an exhaustive set of test cases that enables testers
to deliver consistent and complete results.

- [OWASP Mobile Application Security Verification Standard
  (MASVS)](https://mas.owasp.org/MASVS/) provides a baseline for complete and consistent security tests for both iOS and Android.
- [OWASP Mobile Application Security Testing Guide (MASTG)](https://mas.owasp.org/MASTG/) is a comprehensive manual covering the processes, techniques, and tools used during mobile application security analysis, as well as an exhaustive set of test cases for verifying the requirements listed in the MASVS.
- The [OWASP Mobile Application Security Checklist](https://mas.owasp.org/checklists/) contains links to the MASTG test cases for each MASVS control.
  - Security Assessments / Pentests: Ensure you're at least covering the standard attack surface and start exploring.
  - Standard Compliance: Includes MASVS and MASTG versions and commit IDs.
  - Learn and practice your mobile security skills.
  - Bug Bounties: Go step by step covering the mobile attack surface.

Consider leveraging the OWASP MAS to enhance your iOS and Android application
security, testing, and authentication capabilities.

### Android

When developing Android applications, another resource to consider are the
Android community application best practices. The [Security
guidelines](https://developer.android.com/privacy-and-security/security-tips) contain best-practices guidance on enforcing secure
communications, defining the correct permissions, safe data storage, service
dependencies and more.

### iOS

When developing iOS applications, consider Apple's [Introduction to Secure
Coding Guide](https://developer.apple.com/library/archive/documentation/Security/Conceptual/SecureCodingGuide/Introduction.html), which contains best practices for the iOS
Platform.

## Data collection, usage, and retention

Google Maps Platform is committed to transparency regarding data collection,
data usage, and data retention. Google Maps Platform's data collection, usage,
and retention are subject to the [Google Maps Platform Terms of
Service](https://cloud.google.com/maps-platform/terms/), which includes the [Google Privacy
Policy](https://policies.google.com/privacy).

### Data collection

Data is collected through use of Google Maps Platform Products. As a customer,
you are in control of what information you transmit to Google Maps Platform
through APIs and SDKs. All Google Maps Platform requests are logged, which
include response status codes from the product.

#### Google Maps Platform logged data

Google Maps Platform logs data across the product suite. Logs contain multiple
entries which typically include:

- **Account identifier** which can be an API key, Client ID, or Cloud project number. This is required for operations, support, and billing.
- **IP address** of the requesting server, service, or device. For APIs, note that the IP address sent to Google Maps Platform will be dependent on how the API invocation is implemented in your application/solution. For SDKs, the IP address of the invoking device is logged.
- **Request URL** , which contains the API and parameters being passed to the API. For example, the [Geocoding API](https://developers.google.com/maps/documentation/geocoding/requests-geocoding) requires two parameters (address and API key). Geocoding also has a number of optional parameters. The request URL would contain all parameters passed to the service.
- **Date and time** of the request.
- **Web applications** have **request headers** logged which typically include data such as type of web browser and operating system.
- **Mobile Applications using an SDK** (Android and iOS) have the version, library,and application name logged.

#### Google Maps Platform log access

Access to logs is highly **restricted** and **authorized** only to specific team
members who have a **legitimate** business need. Each **access** request to the
log files is documented for **auditing** purposes, which is verified through
Google's ISO 27001 and SOC 2 third-party audits.

### Data usage

Data collected by Google Maps Platform is used for the following purposes:

- Improving Google products and services
- Providing customer technical support
- Operational monitoring and alerting
- Maintaining platform security
- Platform capacity planning

Please note that Google does not sell your personal information to third parties as documented in [Google's Privacy Policy](https://policies.google.com/privacy).

### Data retention and anonymization

User data collected in Google Maps Platform logs may be retained for various lengths
of time based on business needs, subject to storage and retention policies. User data is retained only when there is a legitimate business need, and it is deleted when it is no longer necessary for the purposes for which the data was collected. Acceptable means of deletion are strictly defined and include all layers through garbage collection. Deletion processes are monitored and verified to ensure compliance.

Anonymized, aggregate usage statistics derived from logs may be retained longer. All data anonymization is reviewed by the privacy team to ensure that it meets a sufficient technical standard and is appropriate to meet privacy, product, and regulatory needs.

## Support for compliance requirements

Google Maps Platform regularly undergoes independent verification of its security, compliance and quality controls, and receives certifications, attestations, and audit reports to demonstrate compliance. Key international standards that we are audited against are the following:

- [ISO / IEC 27001 (Information Security Management)](https://mapsplatform.google.com/resources/trust-center/iso-iec-27001/)
- [ISO / IEC 27017 (Cloud Security)](https://mapsplatform.google.com/resources/trust-center/iso-iec-27017/)
- [ISO / IEC 9001 (Quality Management)](https://mapsplatform.google.com/resources/trust-center/iso-9001-2015/)

In addition, our [SOC 2](https://mapsplatform.google.com/resources/trust-center/soc-2/) and [SOC 3](https://mapsplatform.google.com/resources/trust-center/soc-3/) reports are available to our customers. We also participate in sector and country specific frameworks, such as [NIST 800-53](https://mapsplatform.google.com/resources/trust-center/nist-800-53/) and [TISAX](https://mapsplatform.google.com/resources/trust-center/tisax/) (Germany).

For a complete listing of our compliance offerings, see our [Security and Compliance Trust Center](https://mapsplatform.google.com/resources/trust-center/).

# Summary

Security is a primary design criteria for all of Google's infrastructure,
products, and operations. Google's scale of operations and its collaboration
with the security research community enable us to address vulnerabilities
quickly, and often to prevent them entirely. Google runs its own services, such
as Search, YouTube, and Gmail, on the same infrastructure that it makes
available to its customers, who benefit directly from Google's security controls
and practices.

Google believes that it can offer a level of protection that few public cloud
providers or private enterprise IT teams can match. Because protecting data is
core to Google's business, we can make extensive investments in security,
resources, and expertise at a scale that others cannot. Google's investment
frees you to focus on your business and innovation. We will continue to invest
in our platform to let you benefit from Google services in a secure and
transparent manner.

# What's Next

- To learn more about our security culture and philosophy, read [Building Secure and Reliable Systems (O'Reilly book)](https://www.oreilly.com/library/view/building-secure-and/9781492083115/).

- To learn more about recommended best practices, read [Google Maps Platform security guidance](https://developers.google.com/maps/api-security-best-practices.md.txt).

- To learn more about product coverage by compliance certification, see [Google Maps Platform Services in scope by compliance program](https://developers.google.com/maps/security/compliance/services-in-scope.md.txt).

- To learn more about our approach to managing incidents, read [Google Maps Platform Incident Management](https://developers.google.com/maps/incident-management.md.txt).