Business analyst is one of the most keyword-driven searches in corporate hiring. Recruiters query "requirements gathering," "process mapping," "user stories," "UAT," and "stakeholder management" almost verbatim, both in their ATS and on LinkedIn, because BA work is defined by a shared vocabulary in a way few other jobs are. Your resume needs those exact phrases attached to real outcomes, or it never surfaces. That is the mechanical half of the problem. The judgment half is that everyone who applies has the same phrases, so the recruiter's second pass looks for consequence: what happened because your requirements were good.
Who reads a BA resume matters for how you write it. The first pass is usually a corporate recruiter with no analysis background running keyword and methodology matches (Agile vs waterfall, the domain, the tools). The second is the hiring manager, typically a senior BA, product owner, or delivery lead, who reads your bullets the way they would read a requirements document: checking for precision, scope discipline, and whether your claims are testable. A bullet like "improved processes across the organization" fails that reader instantly; "mapped the servicing process in BPMN, removed 11 handoffs, cycle time fell from 9 days to 4" passes because it is specific enough to probe in an interview.
The differentiator above the keyword floor is consequence: requirements that prevented rework, processes that got measurably faster, systems that users actually adopted, migrations that converted without data defects. "Gathered requirements" is a floor; "requirements that survived UAT with 4 change requests instead of the platform average of 30" is a hire. Every artifact a BA produces exists to prevent an expensive downstream failure, so the strongest bullets name the failure that did not happen: rework avoided, defects caught before conversion weekend, audit reviews passed with zero findings, a build-vs-buy decision made on evidence instead of vendor slides.
Domain matters more than most candidates admit. A BA who knows loan servicing, claims processing, or supply chain gets shortlisted over a generalist with identical skills, because half the job is knowing which questions to ask and the domain teaches you the questions. Name your domains explicitly in the summary (banking, insurance, healthcare, logistics) and name the systems (loan-servicing platforms, policy administration, an ERP by brand if you can). If you are switching domains, lean on the transferable systems work (migrations, integrations, UAT at scale) and mirror the target domain's vocabulary from the posting wherever it truthfully applies.
For the work experience section, structure each role around artifacts, scale, and outcomes. Artifacts prove you do the actual work: user stories, acceptance criteria, BPMN maps, data dictionaries, traceability matrices, UAT scripts. Scale sizes the work: 120 stories per release, 400K policies migrated, 90 fields mapped, 20 testers coordinated. Outcomes prove the work was good: change requests down 60%, cycle time halved, zero post-launch data defects, on-date go-lives. Three to five bullets per role, each pairing at least two of the three. Avoid pure activity bullets ("attended stand-ups," "participated in workshops"); a BA resume full of participation reads as a note-taker, and note-takers do not get BA II salaries.
For the skills section, split analysis skills from tools and keep both literal. Analysis: requirements elicitation and documentation, process mapping (BPMN), user stories and acceptance criteria, UAT planning, gap analysis, data mapping. Tools: Jira, Confluence, Visio or Lucidchart, SQL, Excel, and a BI tool (Tableau or Power BI) if you have one. SQL deserves special treatment: it is the single highest-leverage line on a BA resume in 2026, a common hard filter on technical-BA postings, and the clearest signal that you validate with data rather than opinion. State your level honestly ("SQL for data validation and profiling") rather than leaving a bare "SQL" that invites a live test you might not want.
For education and certifications, the pattern is degree plus one credible credential. A bachelor's in business, information systems, or a domain field satisfies nearly every posting; an unrelated degree is fine once you have BA experience above it. Certifications carry real weight in banking, insurance, and government: IIBA's ECBA (entry), CCBA (mid), and CBAP (senior, requiring 7,500 documented hours) pass actual filters, and PMI-PBA appears at project-heavy shops. Agile shops respect CSPO or a Scrum credential as evidence you know the ceremonies. List exact names, issuers, and dates in their own section. If you have none, one in progress with an expected date beats an empty section, and it costs less than most candidates think.
For formatting, produce the document a requirements reviewer would approve: single column, standard headings, consistent tense and date formats, no graphics or skill meters. BAs are hired to write precisely, so typos and inconsistent formatting are read as work samples, not oversights. One page up to about seven years of experience, two pages after that is fine and normal in this field. Keep bullets under two lines each, front-load the outcome, and export to PDF. A clean ATS-friendly template parses reliably and, just as importantly, looks like the structured artifacts you claim to produce.
The recurring mistakes on business analyst resumes are vagueness, tool-listing without evidence, and scope inflation. Vagueness: "liaised between business and IT" describes every BA who ever lived and distinguishes none. Tool-listing: naming Jira, SQL, and Tableau in skills while zero bullets show them in use, which reviewers notice immediately. Scope inflation: claiming you "led" a program when you documented requirements for one workstream; hiring managers calibrate scope in the first interview question and the mismatch costs credibility. Also common: burying UAT and traceability work because it feels unglamorous, when audit-clean traceability is exactly what regulated employers pay premiums for.
Lead the top third with a summary, not an objective. Three lines: years and domain ("business analyst with 5 years in banking and insurance systems"), your strongest artifact scale ("requirements for 8 implementations"), and one consequence metric ("cut UAT change requests 60%"). This is the text a recruiter reads while deciding whether to keep scrolling, and it should contain your best searchable phrases naturally. Objectives are for career changers only, and even then should center what you have already analyzed, not what you hope to learn. More constructions in these summary examples.
Tailor to each posting, because "business analyst" spans wildly different jobs behind one title. A technical-BA posting (data mapping, APIs, SQL) wants your migration and validation bullets first; a process-BA posting (BPMN, operating model, change management) wants your mapping and workshop bullets first; an Agile product-adjacent posting wants stories, backlog, and sprint vocabulary. Mirror the posting's methodology and artifact names exactly where they are true of your work; recruiters screen delivery-model fit early and literally. Ten minutes of tailoring against the job description reorders your existing bullets into the shape each reviewer expects.
The 2026 reality: AI tooling now drafts user stories, summarizes workshops, and generates first-pass process maps, and employers have noticed. What they hire for is what the tooling cannot do: extracting the real need from a stakeholder who states a solution, arbitrating between rival departments, knowing which requirement is load-bearing, and owning sign-off. Position yourself on that side: elicitation, facilitation, decision framing, and validation with data. Bullets like "facilitated 30+ workshops, converting stakeholder conflict into prioritized, costed requirement sets" are 2026-proof; "documented meeting notes" is not. Use the example below as a skeleton, swap in your artifacts and consequences, and check the parse with an ATS-friendly structure before sending.