If you still close offers to engineers, data scientists and security specialists on salaries negotiated case by case, you have a problem. Not only an internal ordering problem. A compliance one.
The confusion is understandable. The EU pay transparency directive — Directive (EU) 2023/970 — had to be transposed into national law by 7 June 2026, and Spain missed that deadline. The Ministry of Labour opened a consultation on a draft in April 2026; it closed in May, and as of August 2026 there is no approved text. A lot of companies have read that as "nothing has changed yet".
That reading is wrong in a way that costs money. Spain has had its own pay transparency obligations in force since April 2021 — a pay register at every company size, equal pay for work of equal value, and a pay audit at 50 or more employees — and they apply whether or not the EU directive has been transposed, including to a foreign company with three employees in Madrid.
This guide covers what already binds you, what arrives with the transposition, and how to get your bands in order before either one becomes a problem.
What is already mandatory in Spain, today
Three obligations are in force now, independent of the directive.
Every company must keep a pay register. Regardless of headcount. It has to record, broken down by sex and by professional group, category or job of equal value, the average and median values of salary, salary supplements and non-salary payments across the entire workforce. One employee or one thousand. This has been the rule since April 2021, and a company that cannot produce it on request is exposed to fines running from roughly €751 to €7,500, the band for a grave infringement under the LISOS sanctions regime.
Equal pay for work of equal value is a statutory obligation, not an aspiration. If two people doing work of equal value are paid differently, you need an objective, documentable reason. "That is what they asked for" is not one. Neither is "we had to move fast".
At 50 employees you cross a real threshold. Companies with 50 or more employees must have an equality plan and, as part of it, a full pay audit: a diagnosis of the pay situation, a job valuation system, and corrective measures where unjustified gaps appear.
What the transposition will add, and what is not in force yet
None of the following binds you today. The directive layers on obligations Spanish law does not yet have in this form: telling candidates the starting salary or band before the interview, a ban on asking about pay history, the right of employees to know average pay levels for their category broken down by sex, periodic gap reporting for larger employers, and corrective action where an unjustified average gap above 5% appears in a category. Confidentiality clauses that stop employees discussing their own pay become unenforceable.
Two of those — publishing the band and dropping the pay-history question — are process changes you should make now regardless of the legal calendar, and the rest of this guide explains why.
Size changes the burden, not the obligation
The bands below are the directive's reporting thresholds. None of them applies in Spain until the transposition lands; the pay register applies today at any size. The directive presses hardest on large employers, but the practical impact starts much earlier.
- Over 250 employees. You need your house in order already: job families, levels, evaluation criteria, and traceability of pay decisions.
- 150 to 249 employees. This is where scaleups accumulate poorly handled exceptions. Fast promotions, counteroffers, out-of-band hires, and managers applying different criteria.
- 100 to 149 employees. Periodic reporting stops being a distant topic and starts requiring usable data.
- Under 100 employees. You are not exempt. The pay register applies at any size, and the transparency rules in recruitment and the individual right to pay information will reach you too.
The practical test is simple: if you cannot explain why two people in jobs of equal value are paid differently, you do not have a pay policy.
In technology this happens constantly. A platform engineer hired during a shortage. A data scientist brought in on an aggressive counteroffer. An engineering manager promoted without recalibrating the band. If you have not decided in advance what carries weight — specialisation, impact, seniority, leadership, role complexity — every exception becomes a precedent. And every precedent complicates hiring, promotion, internal audit and your credibility with the team.
Publishing bands without breaking your hiring process
You open a Staff Engineer role, forty solid applications arrive, and on the first call three candidates stop you with the same question: "What's the band?" If your answer is still "it depends", you are already behind.
Most of the problems do not appear when you publish the range. They appear before that, when the company has not decided what it is buying. Plenty of startups open a Senior Backend Engineer role intending to set the band after seeing candidates. That will not survive the transposition, and it already costs you candidates.
Publishing well requires four decisions first:
- Set the band before opening the role. Not after the first interview, and not after seeing what a strong candidate asks for.
- Fix the actual level. Senior, Staff, Lead and Engineering Manager cannot share one description and differ only in salary.
- Separate fixed and variable. Bonus, on-call, phantom shares and objective-based variable pay each need explaining separately.
- Translate the scope into concrete criteria. Architecture, ownership of critical systems, mentoring, on-call, product impact, coordination with the business.
A worked example: if you are hiring a Senior Data Scientist to build models in production, the posting has to make clear whether you are paying for applied research, for real deployment into the product, or for technical leadership of a team. Without that precision the range looks arbitrary and the process loses credibility.
Publishing a band improves the process because it forces you to decide earlier, aligns recruiters and hiring managers, and filters better from the first conversation.
What you can ask, and what to delete today
Many teams get this wrong out of habit. Exploring salary expectations is still valid. Asking what a candidate currently earns, what they earned at their last company, or what they would need to beat an existing offer is the practice the directive removes — and the one to drop now, ahead of the transposition.
The distinction matters enormously in tech. For years companies anchored offers to a candidate's previous salary. That habit rewards market distortions. An underpaid ML engineer arrives with a low reference. An engineering manager hired by a well-funded scaleup arrives with a high one. Anchor on that and you are not paying for the value of the role — you are inheriting another company's mistakes.
Use this standard in interviews:
- Right: "The band for this role is between X and Y. I want to confirm that fits your expectations."
- Wrong: "What are you earning now, so we can see how much room we have?"
- Right: "Let me explain how we set the level and what it would take to enter the top of the band."
- Wrong: "Tell me your history first and then we'll see where to place you."
Concrete changes for CTOs, founders and hiring managers
Do not delegate this entirely to People. In technology startups a large share of the risk sits in interviews run by founders, managers and leads who improvise.
Make these changes now:
- Clean up scorecards and interview scripts. Delete any question about current salary, previous salary or "last payslip".
- Block opening a role without an approved band. No validated range, no posting.
- Train the technical panel. Whoever interviews should be able to explain why a candidate lands at the bottom, middle or top of the band.
- Avoid ambiguous promises. "We'll adjust it later" and "if you're a fit, I'm sure we'll work it out" generate distrust and complicate closes.
- Review external recruiters. If an agency is still asking about pay history on your behalf, the problem is also yours.
If you already operate across several countries, with different contract types or variable components, get every component of pay documented now. What you publish must match what you can defend internally.
Internal obligations: valuation, information, audit
Your CTO promotes a senior backend engineer, HR adjusts a data scientist's offer to avoid losing them, and six months later an employee asks for the average salaries in their category broken down by sex. Without clear levels, progression criteria and documented exceptions, you will not answer with data. You will improvise.
Job valuation systems
In a technology startup the typical error is paying by intuition and describing levels with titles nobody uses consistently. "Senior" can mean technical ownership of a team in one company and years of service in another. That breaks any pay defence you might mount.
Put your structure in order with a job valuation system that works for hiring, promotion and justifying differences. At minimum it has to answer:
- What creates value in each role. Technical complexity, product impact, system criticality, autonomy, people management, cross-functional influence.
- What separates one level from the next. A Software Engineer II is not paid more for tenure. They are paid more for solving larger-scope problems, making better decisions and operating with less supervision.
- Which exceptions you accept. A hard-to-find staff engineer, an international hire, a different variable-pay structure in another market. If you make an exception, write down why before someone asks.
The employee right to information
Saying salaries are private is not an answer. You need to classify each role properly, group comparables and produce data that does not contradict itself between areas.
Define an internal protocol before the first request arrives. Decide who receives it, who validates which roles are comparable, who prepares the response, and where it is recorded. Leave this to an individual manager without a common standard and you will end up with different answers to similar cases.
In companies with engineering, product and data teams this usually fails for one specific reason: titles do not reflect the real value of the job. An analytics engineer may be closer to a data engineer in impact and complexity than to the rest of the analytics team. If your job architecture is wrong, your answer will be wrong too.
Pay audit and corrective measures
Treat the pay audit as a management tool rather than a defensive document. It forces you to check whether pay differences between people in jobs of equal value have an objective reason you can explain without inventing a story afterwards.
The directive sets the reference point at a 5% average gap by professional category: where that gap is unjustified and undocumented, larger employers have to take corrective measures. In a technology scaleup that gap typically appears in three places: urgent AI or cloud hires closed outside the pattern; promotions negotiated under manager pressure; and teams that grew in phases and carry salaries inherited from different contexts.
The rule is this. If you cannot explain a difference through level, scope, responsibility, sustained performance or objective conditions of the role, correct it. "We closed it that way because we were in a hurry" does not work. Neither does "they accepted less".
Run the review with an audit mindset rather than a vacancy-closing one. Compare engineers at the same level across teams, review variable pay and supplements, find the outliers, and document why they exist.
An operational checklist
You do not need an endless project. You need a short, serious, executable plan.
1. Audit what you actually have
Export from your HRIS, payroll or ERP. Group by role, level and area. Look especially at engineering, data, technical product and security — that is where the least justified differences hide, because the market there has been most volatile.
Look for three things: identical jobs paid inconsistently, different titles for very similar work, and opaque supplements such as ad-hoc bonuses or conditions negotiated outside policy.
2. Design bands by role
Do not over-engineer this. You need a structure hiring managers can actually use.
- Define job families: backend, frontend, platform, data, ML, DevOps, security.
- Create levels people actually understand: junior, mid, senior, lead, staff where it applies.
- Attach an internal salary band to each level.
- Document what justifies entering the bottom, middle or top of the band.
- Separate fixed salary, variable and equity.
A classic mistake is creating bands so wide they mean nothing. If your range permits almost any figure, you are not being transparent. You are dressing up opacity.
3. Communicate internally
Do not ship this as a cold PDF from People. Employees do not need corporate messaging. They need to know what changes, what they can ask, and how pay decisions are made from now on.
At minimum: write a pay policy document in plain language, train managers so they do not improvise answers, open a question channel with a named owner, and clarify the progression criteria so nobody misreads what happens at promotion.
Badly communicated transparency generates as much noise as opacity. The difference is explaining criteria, not just figures.
4. Update your ATS and careers page
If you use Greenhouse, Lever, Teamtailor, Workable or Recruitee, review your templates now. The system should require a salary range before a role can be published. If it depends on someone remembering, it will fail.
On the careers page: show the band on every role, avoid phrases like "commensurate with experience", include compensation context where there are benefits, variable or equity, and align the copy with internal reality. Do not promise a culture of transparency if every manager still negotiates independently.
5. Train whoever interviews
This step gets skipped and then breaks everything else. Your CTO, your engineering managers and any founder who interviews need to know which questions to avoid, how to present a band, and how to justify an offer without reaching for the candidate's previous salary. Skip it and you will have an officially correct process and real conversations that sit outside it.
The rule is simple. Every material pay decision should be explainable in writing without embarrassment and without arguments invented after the fact.
Why publishing bands makes hiring better, not slower
Most companies will treat this as a burden. The better ones will use it to differentiate.
The coming ban on the salary-history question will force technology companies to stop basing offers on what a candidate used to earn and to build rigorous, objective valuation frameworks instead. That is a challenge, and it is also the opportunity: fairer, more competitive systems that strengthen the employer brand.
In a competitive technical market a clear compensation policy reduces friction from the first contact. The candidate understands quickly whether they fit, the recruiter saves time, and the manager does not have to improvise a different narrative in every process. It also improves internal perception — not because everyone earns the same, but because the differences stop looking arbitrary.
The failures that end in complaints are rarely bad faith. They are bad execution: absurdly wide ranges that inform nothing, poorly defined levels where two people do nearly the same job under different titles, undocumented exceptions for urgent hires, managers still asking about previous pay, and promotions granted without written criteria.