Product security is the job of keeping a software product safe across its whole life, from design to code to the software supply chain to the cloud it runs on. It grew out of application security (AppSec), a narrower field that only covers a single app’s code and runtime.
Three forces are pushing this shift right now: new laws that require proof of security, attacks that hit the software supply chain, and the rise ofAI-written code.
12 key findings
1. The industry has no fixed job title yet.
BSIMM16, a yearly benchmark study of software security programs, treats “application security group” and “product security group” as the same thing, not separate roles.
2. Teams have a skills problem, not just a headcount problem.
In ISC2’s 2025 survey of 16,029 security leaders, 59% reported a critical or significant skills gap, up from 44% in 2024.
3. Security staff stay thin next to engineering staff.
BSIMM14 found 1.38 security team members for every 100 developers. That roughly 1:100 ratio has become the industry benchmark.
4. Security champions do most of the scaling work.
A champion is a developer who volunteers to help with security part-time. BSIMM16 counted about 6,500 champions across 223,700 developers, a rate of 2.91 per 100, nearly double the rate of dedicated security staff.
5. New laws are a permanent driver of demand, not a passing trend.
CISA’s Secure by Design pledge has 68 signatories. The EU Cyber Resilience Act took effect in December 2024, and its reporting rules start in September 2026. Both turn product security into a legal requirement.
6. Supply-chain attacks are pushing companies to hire specialists.
Sonatype found 454,648 new malicious open-source packages in 2025, a 75% jump from the year before. The running total has passed 1.233 million.
7. AI is changing what security jobs look like, not cutting them.
GitHub reports that 46% of code in AI-enabled files is written by Copilot. A February 2025 study in the academic journal ACM TOSEM found that a large share ofAI-generated Python code contains security flaws.
8. AI is creating brand-new security jobs.
OWASP, a nonprofit that publishes security standards, released a Top 10 risk list just forAI agents in 2026. In Cisco and Splunk’s 2026 CISO Report (650 respondents), 78% of security chiefs said they already run a team dedicated to AI agent security.
9. Pay is high but varies a lot.
Glassdoor’s 2026 figure puts average total pay at $185,700, in a range of $146,700 to $238,200. Levels.fyi shows individual contributors at large tech firms earning a $281,000 to $335,000 median, with top earners above $600,000.
10. India is becoming a major hub for this work.
Quess Corp reports that Global Capability Centers (GCCs), offices multinational firms run themselves instead of outsourcing, made up 27% of India’s 1.8 million IT hires in 2025, up from 15% in 2024. A specialized security role there still takes 75 to 90 days to fill.
11. Bigger companies give security leaders less direct access to the CEO.
IANS and Artico surveyed hundreds of security chiefs on reporting lines and found that direct access to the CEO drops sharply at larger companies.
12. No single dataset tracks product security headcount, hiring, and pay across the industry.
This report pulls from multiple partial sources because that combined dataset doesn’t exist yet.
What is Product Security?
Product security covers a product’s full life and its supply chain. That’s what sets it apart from the security fields next to it.
| Field | Question it answers | What it produces |
| Application Security | Is this one app’s code and runtime secure? | Automated code scans, dependency scans, and pen-test reports |
| Product Security | Is this product secure across its whole life and supply chain? | Threat models, a Software Bill of Materials (SBOM), secure-design reviews |
| Field | Question it answers | What it produces |
| Cloud Security | Is the infrastructure this product runs on set up securely? | Cloud configuration checks, access-policy reviews |
| DevSecOps | Is security automated inside the build and release pipeline? | Automated pipeline checks, policy-as-code |
| Security Engineering | Can we build tools that make security the easy default? | Internal security platforms, guardrails |
| Platform Security | Is the shared infrastructure hardened for every team using it? | Platform hardening standards |
| Security Architecture | Is the system designed to resist whole classes of attack? | Reference designs, design patterns |
| Security Assurance | Can we prove to auditors and customers that our controls work? | Compliance evidence, formal attestations |
Product security job titles, by level
These 26 job titles show up in real postings and practitioner writing across 5 levels. Not every company uses every title. Smaller companies often fold several of these into one broader role.
These 26 job titles show up in real postings and practitioner writing across 5 levels. Not every company uses every title. Smaller companies often fold several of these into one broader role.
Leadership Roles
| Role | Main job | Typical background | AI exposure |
| CISO | Owns the company’s full security risk | 20+ years in security or IT leadership | Low (oversight, not hands-on) |
| VP Product Security | Sets the security plan across every product line | Engineering leadership plus security depth | Low to medium |
| Head or Director of Product Security | Runs the product security function day to day | Staff or principal engineer promoted into management | Medium |
| Product Security Manager | Manages a team of engineers against a roadmap | Senior individual contributor promoted into a first management role | Medium |
Engineering Roles
| Role | Main job | Typical background | AI exposure |
| Product Security Engineer | Builds security into product design and code | Software engineer with a security specialty | High (AI code review, threat-model copilots) |
| Security Software Engineer | Builds security tools and platforms | Backend or platform engineer | High |
| Application Security Engineer | Runs code and dependency scans, triages findings | AppSec analyst promoted into engineering | Very high (first-pass triage is easy to automate) |
| Security Automation Engineer | Automates security workflows and pipelines | DevOps or site reliability background | High |
| Security Platform Engineer | Builds the shared security platform other teams use | Platform engineer | Medium to high |
Specialist roles
| Role | Main job | Typical background | AI exposure |
| Threat Modeling Engineer / Security Architect | Analyzes risk in new systems before they’re built | Systems or security architecture background | Medium (AI helps with diagrams, humans make the call) |
| Product Security Researcher / Vulnerability Researcher | Finds new types of vulnerabilities | Offensive security or CTF competition background | Low to medium (AI helps, doesn’t replace original research) |
| Software Supply Chain Security Engineer | Secures the build pipeline, dependencies, and SBOMs | DevOps plus security | Medium, and growing fast per Sonatype’s 2026 data |
| Cloud Product Security Engineer | Secures cloud-native product architecture | Cloud security plus product engineering | Medium |
| API Security Engineer | Secures APIs and permission models | Backend engineer plus AppSec | Medium to high |
| Mobile Security Engineer | Secures mobile apps and their supply chain | Mobile engineer plus AppSec | Medium |
| AI/ML Security Engineer | Secures ML pipelines, training data, and model files | ML engineer plus security | Not applicable, this role secures AI systems rather than using them |
| AI Product Security Engineer | Secures AI-powered features like agents and LLM tools | Emerging role, no standard training path yet | Not applicable, this is the fastest growing specialist category (see emerging roles below) |
| Detection Engineer | Builds detections for attacks on the product layer | SOC or detection engineering background | High |
| Security Testing Engineer | Runs and scales security test suites | QA or test engineering plus security | Very high |
Program and Enablement Roles
| Role | Main job | Typical background |
| Product Security Program Manager | Runs cross-team security initiatives and roadmaps | Technical program management |
| Security Champions Program Lead | Scales security knowledge through embedded champions | Community-building plus AppSec background |
| Security Education / Developer Enablement | Trains engineers to write secure code by default | Developer relations plus security |
| SecurityAssurance Engineer | Verifies controls actually work, not just that they exist on paper | Audit or compliance plus technical depth |
Governance and Risk Roles
| Role | Main job | Typical background |
| Product Security Risk Manager | Measures and tracks product level risk | Risk management plus technical fluency |
| Security Compliance Engineer | Maps controls to regulations and frameworks | Compliance plus engineering |
| SecurityAssurance Specialist | Produces audit-ready proof that controls work | Governance, risk, and compliance (GRC) background |
How a Product Security Team is Built?
Companies use 6 main models to run product security. Which one fits depends on company size and how mature the engineering org is
| Model | How it works | Best fit | Main failure mode |
| Centralized | One team owns all reviews and decisions | Startups and early scale-ups | Becomes a bottleneck as engineering grows |
| Federated | Each business unit runs its own security function, loosely coordinated | Multi-business-unit enterprises | Standards drift apart between units |
| Embedded | Security engineers sit inside product teams full time | Scale-ups with a strong engineering culture | Hard to keep a consistent bar without strong central architecture |
| Hub-and spoke | A small central team plus a champions network in each product team | Scale-up to enterprise | Champions get under resourced relative to their day job |
| Platform model | Security ships as a self service tool product teams use on their own | Enterprises with mature platform engineering | Needs platform maturity most companies don’t have yet |
| Hybrid | A central architecture and assurance core plus embedded engineers in high-risk product lines | Large, regulated enterprises | Coordination overhead between central and embedded staff |
How many security staff should you have?
No dataset directly measures “product security staff per software engineer.” The closest stand-in is BSIMM’s data on Software Security Groups (SSGs, the core dedicated security team) and security champions, collected from AppSec programs at 111 to 130 firms per year. Treat every ratio below as an estimate built from AppSec data, not a product security-specific measurement.
Using that BSIMM data, combined SSG-plus-champion staffing density grew from 3.12 per 100 developers in 2023 (BSIMM14) to 4.56 per 100 in 2026 (BSIMM16). That’s a directional signal that security staffing is rising industry-wide. It isn’t a claim about what any single company should staff.
This report’s own formula: Product SecurityWorkforce Density Index (PSWDI)
PSWDI = Product Security full-time staff ÷ Software Engineering full-time staff, shown per 100 engineers. Use it to benchmark your own ratio against the BSIMM figures above.
The product security job market
Cybersecurity hiring is holding up better than the rest of tech. Indeed Hiring Lab data from early 2026 shows Security and Public Safety job postings well above their pre pandemic (February 2020) level, while IT Systems, Software Development, and Data Analytics postings all remain below 2020 levels.
Job postings by seniority
Entry-level (under 1 year): 17% of postings, down from 25% in 2022
Mid-level (2 to 6 years): 63% of postings
Senior and expert (over 6 years): 20% of postings
Most requested cybersecurity skills
- AI security: 41% of respondents call it a critical or significant need
- Cloud security: 36%
- Risk assessment: 29%
- Application security: 28%
- Governance, risk, and compliance (GRC): 27%
- Security engineering: 27%
The product security skills gap
Skill scarcity, not headcount, is the main constraint on cybersecurity teams in 2026. In ISC2’s 2025 study of 16,029 organizations, 59% reported a critical or significant skills shortage, up from 44% in 2024.
That shortage breaks into 5 distinct problems:
Skills shortage: Enough people overall, but not enough depth in cloud-native and AI/LLM security.
Experience shortage: Plenty of entry-level applicants, but few candidates who’ve shipped secure code at enterprise scale.
Leadership shortage: Few technical leaders who can bridge engineering work with executive risk conversations.
Specialization shortage: Sharp talent gaps in software supply-chain security and defending against AI agents.
Headcount shortage: Plain body-count deficits in specific high-growth regions.
What makes a great product security engineer?
Strong performers in this field are evaluated across 5 skill areas:
- Technical: Coding ability, systems fundamentals, cloud networking, application architecture, vulnerability analysis, automation.
- Engineering: Code review, system design, build-pipeline integration, developer tooling, system reliability.
- Security: Threat modeling, risk assessment, tracking vulnerabilities through their full lifecycle, security architecture, an attacker’s mindset.
- Human: Cross-team communication, organizational influence, empathy for developers, negotiation, coaching.
- Business: Understanding the cost of risk, feature prioritization, product context, customer impact, regulatory exposure.
Senior and staff-level engineers stand out mainly on business judgment, organizational influence, and architecture-level design skill, not on raw tool knowledge.
Common ways people enter product security
| Starting point | What carries over | What has to be learned |
| Software Engineer → Product Security Engineer | Coding, system design, code review instincts | Attacker mindset, threat modeling, vulnerability classes |
| DevOps/SRE → Cloud Security → Product Security | Infrastructure-as-code, cloud platforms, automation | Application-layer vulnerability analysis, secure design |
| Pentester → Product Security | Attacker mindset, vulnerability research | Engineering collaboration, scaling advice past one-off findings |
| AppSec Analyst → Product Security Engineer | Scanning tools, triage judgment | Software engineering depth, architecture-level thinking |
| Security Researcher → Product Security | Deep expertise in one vulnerability class | Product and business context, day-to-day engineering pace |
| SOC Analyst → Security Engineering | Detection and incident fundamentals | Secure development practices, proactive design work |
Pay and economics
US total pay, 2026
- Glassdoor average, broad market: $185,700, in a range of $146,700 to $238,200 Levels.fyi median, large-tech individual contributors: $281,000 to $335,000, with top bands above $600,000
- BLS baseline for Information SecurityAnalysts: $124,910 median annual wage (May 2024)
Pay by specialty (base salary medians, 2026)
- AI/ML security: $172,000
- Application / product security: $161,000
- Security architecture: $151,000
- Cloud security: $145,000
- DevSecOps: $144,000
- Identity and access management (IAM): $143,000
Pay by region (converted at market exchange rates, not adjusted for cost ofliving)
United States: $124,910 median (BLS, Information SecurityAnalysts, May 2024) India (Bengaluru): about $19,700 median total pay (roughly ₹16 to 17 million at market rates). Adjusted for local purchasing power, this gap narrows a lot in practice. United Kingdom: about $58,000 to $70,000 median total pay across cyber roles
See our full DevSecOps salary breakdown for the United States and what an AI security engineer earns for more detail.
How AI is changing the work
How AI is changing the work
AI is changing what security staff spend their day on, not eliminating the job. Developer use of AI coding tools is now mainstream: GitHub reports 46% of code in AI-enabled files is written by Copilot, and DX telemetry shows 22% of merged code is AI-written across more than 135,000 developers.
How AI splits security work today
- Automate (AI does it, little human judgment needed): First-pass code and dependency scan triage, automated patch generation, boilerplate fix pull requests.
- Augment (AI drafts it, a human decides): Threat modeling support, prompt-injection defense design, secure design reviews.
- Human-led (AI helps little, human judgment leads): Risk acceptance calls, executive communication, research into brand-new vulnerability types, designing permissions for AI agents.
A February 2025 study in ACM TOSEM found that a large share of AI-generated Python code contains security flaws. IDC research on AI code assistants shows developers accept a meaningful share of AI-written code without editing it. Together, that means more code, not less, needs a security check. See our guide to AI in DevSecOps for a deeper look at where this is headed.
Emerging Product Security Roles
Supply-chain and AI risk are creating 8 new specialist roles:
- AI Agent Security Engineer: Handles identity, permission limits, and containment for autonomous AI agents.
- AI/ML Security Engineer: Secures ML pipelines, training data, and model files.
- Software Supply Chain Security Engineer: Manages build-pipeline security, dependency verification, and SBOM generation.
- Security Automation Engineer: Builds automated workflows for triage and fixes.
- Security Platform Engineer: Delivers security controls as a self-service tool for developers.
- AI Red Team Engineer: Attacks AI agents and LLM systems on purpose, before launch, to find weaknesses.
- Security Developer Experience Engineer: Makes internal security tools fit naturally into how developers already work.
- Product Security Data Engineer: Manages the data pipelines behind program metrics and risk scoring.
Product security KPIs and performance
Don’t grade a program by “vulnerabilities found” alone. That count tells you activity happened. It doesn’t tell you whether risk actually went down. Group your metrics into tiers, from raw activity counts up to business outcomes, and put your heaviest weight on the outcome tiers when you report to executives.
The product security maturity model
Organizations move through 6 stages:
- Level 1, Reactive: Security only shows up after an incident. No proactive reviews.
- Level 2, Emerging: Named security leads exist, but there’s no standard tooling or process.
- Level 3, Structured: Standard tools, documented processes, and defined roles across all applications.
- Level 4, Integrated: Security is built into the standard development pipeline and developer workflows.
- Level 5, Product-Native: Security requirements shape product design from the earliest idea stage.
- Level 6, AI-Augmented: AI systems handle routine triage and fixes under human oversight.
This mirrors the pattern in our DevSecOps maturity model (DSOMM) and AI security maturity model, which break the same climb into more detail.
Product Security by Industry
| Sector | How much regulation pushes hiring | What staffing model looks like |
|---|---|---|
| Financial Services | Very high (SEC, banking regulators, PCI-DSS) | Centralized or hybrid, large dedicated teams |
| Defense / Government | Very high (FedRAMP, NIST, sector rules) | Centralized, heavy on compliance |
| Healthcare | High (HIPAA and similar rules) | Hybrid, compliance-driven |
| Technology / SaaS | Moderate and rising (EU CRA applies broadly) | Embedded or platform model, engineering-led |
| Automotive | Rising fast (connected-vehicle rules, UN R155) | A dedicated function is just now forming |
| Telecommunications | High (critical infrastructure status) | Centralized or hybrid |
| E-commerce | Moderate (PCI-DSS, consumer data law) | Embedded, engineering-led |
| Energy | High (critical infrastructure, IT/OT convergence) | Centralized, moves slowly |
| Manufacturing | Moderate and rising (connected-device convergence) | A dedicated function is just now forming |
| Gaming | Low to moderate | Embedded, thin dedicated staffing |
| Media | Low | Thin or outsourced |
India and Global Capability Centers
Outside the US, India’s Global Capability Centers (GCCs), offices multinational companies run themselves instead of outsourcing, are the fastest-growing hub for product security hiring.
Quess Corp data shows GCCs drove 27% of all India IT hiring in 2025. Specialized cybersecurity roles there still take 75 to 90 days to fill on average.
The US product security landscape
The US market has a real labor shortage combined with expanding legal requirements.
- Labor supply: CyberSeek recorded over 500,000 open cybersecurity roles as of early 2026, with far fewer qualified workers available than openings.
- Where the jobs are: Openings cluster in Virginia, California, and Texas.
- Growth forecast: The Bureau of Labor Statistics projects Information Security Analyst roles will grow 29% from 2024 to 2034, adding about 16,000 new positions a year.
- SEC rules: Public companies must disclose material cyber incidents within 4 business days (Form 8-K) and report on governance annually (Form 10-K). Both create ongoing product-risk-management work.
Product security leadership
A modern Head of Product Security needs real engineering credibility as a baseline, not a bonus. Practitioners agree on this without needing a formal survey to prove it: a leader who can’t review a design document or read a code diff loses the trust of the engineers they’re supposed to guide.
Beyond engineering depth, the role now also needs business judgment, organizational design skill, and the ability to explain risk to executives. New for 2026: AI literacy specific to AI agents and large language model (LLM) risk.
Where product security reports to
Product security leadership usually reports up through the CISO. That means how much direct access a product security leader gets to top executives depends on how many layers sit between the CISO and the CEO, and as the findings above show, that access shrinks fast at larger companies.
The future of product security
Four scenarios describe where the field could head by 2030.
| Scenario | What happens to headcount | What would have to be true |
|---|---|---|
| A: Conservative evolution | Headcount grows roughly in step with engineering headcount; today’s org models stay in place | AI tools stop improving at security-specific tasks; regulators stay light on enforcement |
| B: AI-augmented security | Headcount grows slower than engineering headcount as AI absorbs first-pass work; senior roles carry more relative weight | AI copilots become reliable enough for “augment” tasks without creating new failure modes |
| C: Engineering-native security | Dedicated product security headcount shrinks as the function fully merges into engineering; total security work may not shrink | The platform model (described above) becomes the norm, not the exception |
| D: Autonomous product security | Human staff concentrate on oversight, exceptions, and new-risk research; routine work runs largely on its own | AI agents reach reliability and auditability levels not yet proven as of this report |
Our DevSecOps trends for 2026 and AI security trends for 2026 cover the near-term end of this same trajectory.
What the product security engineer job looks like in 2030
By 2030, individual contributors are expected to spend much less time on manual vulnerability triage and scan management. Daily work will shift toward:
- Reviewing overnight AI-generated threat models across product changes
- Deciding on complex business risk exceptions with legal and product teams
- Reviewing autonomous AI agent permissions and containment limits before launch
- Red-teaming AI systems on purpose to find weaknesses
- Reporting product-wide risk numbers to executive leadership
Strategic recommendations, by role
Each group below gets a plan in 3 time frames: NOW (0 to 6 months), NEXT (6 to 18 months), and LATER (18 to 36 months).
CISOs
| NOW | NEXT | LATER |
| Compare your product-security-to-engineering ratio against the roughly 1:100 BSIMM figure above, and write down the gap. | Start or formalize a security champions program. BSIMM16 shows champion density is nearly double dedicated-staff density, the highest-leverage scaling lever you have. | Move toward a hybrid model that pairs a central architecture and assurance core with embedded engineers in your highest-risk product lines. |
CTOs / VP Engineering
| NOW | NEXT | LATER |
| Start EU Cyber Resilience Act readiness now. Vulnerability-reporting duties start September 2026, and building an SBOM takes real lead time. | Fund an AI and agentic-security specialty inside your product security team. 78% of surveyed CISOs already have one. | Invest in platform maturity so security ships as a self-service capability, not a manual approval gate. |
Product security leaders
| NOW | NEXT | LATER |
|---|---|---|
| Track at least one metric from each tier in the KPI section above. Retire “vulnerabilities found” as your only headline number. | Build threat-modeling-as-code into your development pipeline instead of running it as a separate review step. | Build real individual-contributor and management career ladders, using the role-tier tables above, so senior talent has a reason to stay. |
Engineering leaders
| NOW | NEXT | LATER |
|---|---|---|
| Find your teams generating the most AI-written code and route them to elevated review. The ACM TOSEM finding above, that AI-generated Python snippets carry a meaningful rate of security flaws, tells you where to look first. | Work with product security to decide which tasks from the AI task breakdown above your teams should automate first. | Treat secure-by-design as a product requirement, held to the same standard as performance or reliability. |
HR and talent leaders
| NOW | NEXT | LATER |
|---|---|---|
| Write job postings around specific skills, like cloud-native and AI/LLM security, instead of years-of-experience cutoffs. Skills scarcity, not headcount, is the real constraint (see the skills-gap section above). | Build pay bands using percentiles, not averages, once you have enough data points from the compensation data above. | Partner with universities and training providers (below) to build a hiring pipeline for the AI-era specialist roles listed above. |
Recruiters
| NOW | NEXT | LATER |
|---|---|---|
| Expect a 75 to 90 day time-to-hire for niche product security skills, matching the India hiring data above. Set that expectation with candidates and hiring managers. | Build sourcing pipelines specifically for the emerging roles listed above. They won’t show up yet in standard title searches. | Track job-posting demand data as this report’s ongoing data collection matures, to spot demand shifts before they hit pay data. |
Universities
| NOW | NEXT | LATER |
|---|---|---|
| Check whether your security curriculum covers AI/LLM security and software supply-chain security. Both are 2025-2026 additions to the field, not legacy AppSec topics. | Build project-based coursework around the 5-domain skill list above, not just technical checklists. | Partner with employers on apprenticeship-style pipelines. There’s a 3 to 5 year lag between curriculum design and hiring-market relevance. |
Cybersecurity training providers
| NOW | NEXT | LATER |
|---|---|---|
| Build or expand AI/LLM and agentic-security curriculum. It’s the fastest-growing specialty documented in the emerging-roles list above. | Build assessment tools against the 5-domain skill list above, so employers can test real skill, not just check for a certificate. | Track the maturity-model levels above and align your training tiers to organizational maturity stages, not just individual seniority. |
Individual security professionals
| NOW | NEXT | LATER |
|---|---|---|
| Read the AI task breakdown above and be honest about how much of your current role sits in the “Automate” category. | Build real depth in one of the emerging specialties listed above. AI/agent security and supply-chain security have the strongest evidence behind them. | Invest deliberately in the Human and Business skill areas from the 5-domain list above. They separate senior performers from junior ones more than raw technical depth does. |
Sources:
| Tier | Examples | How it’s used |
|---|---|---|
| 1 | CISA, NIST, ENISA, official EU text, peer-reviewed research (for example, ACM TOSEM) | Highest-confidence evidence, used for regulatory facts and measured findings |
| 2 | ISC2, BSIMM/Black Duck, Verizon DBIR, Sonatype, OWASP, Splunk/Cisco | Primary workforce and threat-landscape evidence, generally large samples |
| 3 | Gartner, Forrester, Quess Corp, IANS/Artico, Glassdoor, Levels.fyi | Directional market evidence, smaller or self-selected samples |
| 4 | Practitioner blogs, vendor marketing content | Used sparingly, only to back up Tier 1-3 findings, never as a lone source |
Confidence rating scale
| Rating | What it means |
|---|---|
| A | Primary, high confidence: large sample, an authoritative source, or an official disclosure |
| B | Strong secondary: a credible named source and reasonable sample, may stand in for product security specifically |
| C | Directional: small sample, self-reported, or built by analysis rather than direct measurement |
| D | Weak or incomplete: a real research gap, shouldn’t be cited as a standalone fact |
Formulas used in this report:
- Product Security Workforce Density Index (PSWDI) = Product Security full-time staff ÷ Software Engineering full-time staff, per 100 engineers.
- 2024 malicious-package estimate = the 2025 observed count ÷ 1.75, based on Sonatype’s disclosed 75% year-over-year growth rate.
- Nominal India-US pay gap = a direct currency conversion at roughly 95 Indian rupees to 1 US dollar, not adjusted for local purchasing power.
