The business analyst role is defined by a single question: did the thing that got built solve the problem that was actually there? A CV that lists documentation types answers a different question. What reviewers want is evidence that you found the real requirement, including the ones nobody articulated, and that the delivered solution worked.
Process modelling is the most under-used piece of evidence on BA CVs. Being able to say you mapped a 40-step as-is process and removed 14 of the steps is concrete, visual and immediately credible. So is naming the notation you use.
The other thing worth stating plainly is where you sit. A BA in a waterfall programme writing a 90-page requirements specification and a BA embedded in a scrum team writing stories two sprints ahead are doing different work with the same title.
This example is written for a business analyst with six years across financial services and operations change.
Opens in the editor with this content already filled in, so you can replace it with your own.
Mahnoor Malik
Business Analyst · Process Improvement & Requirements Delivery
mahnoor.malik@example.co.uk
+44 7700 900825
Glasgow, United Kingdom
linkedin.com/in/example-mahnoor-malik
Profile
Business analyst with six years in general insurance and operations change. Work covers a claims intake redesign that removed 14 process steps and four handoffs, requirements for a policy amendment journey across three functions, and self-service SQL analysis that halved escalations on one product. BCS Diploma in Business Analysis.
Core Skills
ElicitationStakeholder workshops, Structured interviews, Process observation, Document analysis
Modelling & DocumentationBPMN 2.0, UML use cases, As-is and to-be mapping, User stories and acceptance criteria
AnalysisGap analysis, Root cause analysis, Cost-benefit analysis, MoSCoW prioritisation
DataSQL, Excel (Power Query), Power BI, Data mapping
DeliveryBacklog refinement, User acceptance testing, Traceability matrices, Change impact analysis
Professional Experience
Senior Business AnalystFebruary 2022 – Present
Clydebank General Insurance · Glasgow, United Kingdom
•Mapped the 41-step as-is claims intake process in BPMN and designed a to-be process with 27 steps, removing four handoffs between the contact centre and the back office.
•Ran nine elicitation workshops across claims, underwriting and compliance for the new policy amendment journey, resolving a conflict between compliance record-keeping and the two-minute handling target.
•Queried three years of complaint records in SQL and found 62% of escalations came from one product variant with an ambiguous renewal notice; rewriting the notice halved escalations on that product.
•Wrote 130 UAT scenarios and coordinated testing with 12 business users, logging 41 defects of which 9 were requirement gaps rather than build errors.
•Mentor two junior analysts on process modelling and acceptance criteria writing.
Business AnalystAugust 2019 – January 2022
Northburn Operations Services · Edinburgh, United Kingdom
•Delivered requirements for a customer onboarding replacement across two business units, working two sprints ahead of the build team.
•Produced the data mapping for a migration of 240,000 customer records, including the reconciliation approach used to sign off the cutover.
•Introduced a standard acceptance criteria format after a release shipped with three differing interpretations of the same story.
Selected Projects
Claims intake redesign
Lead business analyst
•As-is and to-be process modelling, requirements and UAT for the end-to-end claims intake journey.
•Average intake handling time fell from 11 minutes to 7 in the six months after release.
Professional Qualifications
BCS International Diploma in Business AnalysisNovember 2021
BCS
BCS Practitioner Certificate in Requirements EngineeringMay 2020
BCS
Education
MA (Hons) EconomicsSeptember 2015 – June 2019
University of Glasgow · Glasgow, United Kingdom
Upper Second Class (2:1)
Languages
EnglishNative
UrduC1
PunjabiB2
Business Analyst example on the Modern Professional layout. All details are fictional and shown for demonstration only.
What recruiters expect
Before writing anything, it helps to know what the person reading is checking for. In this field that is usually a short, specific list:
Elicitation technique: workshops, interviews, observation, document analysis - not just "gathered requirements".
Process modelling with a named notation, and the size of the processes mapped.
The delivery context: agile, waterfall or hybrid, and the artefacts that context expects.
Data literacy. Increasingly BAs are expected to query data themselves rather than request extracts.
Evidence that the solution worked after delivery, not just that it was specified.
Recommended CV structure
This is the running order the example uses. It is a starting point rather than a rule, but the order reflects what tends to be read first in this profession.
Profile — Three or four lines positioning you for the role.
Core Skills — Grouped skills, for example "Languages" and "Tooling".
Professional Experience — Paid roles, in reverse chronological order.
Selected Projects — Work you built, with outcomes and the stack used.
Professional Qualifications — Completed certifications with the issuing body.
Education — Degrees, diplomas and school-leaving qualifications.
Languages — Spoken languages with CEFR levels.
Sections worth adding
Continuing Professional Development — Useful when moving between domains such as finance to healthcare.
Skills worth including
Grouped rather than listed in one block. Grouping makes a long list readable and shows that you can tell the difference between the things you use daily and the things you have touched.
Beyond the technical list: Asking the question nobody wants asked, Facilitating between operations and technology, Writing unambiguously, Managing conflicting stakeholder priorities. These belong inside your experience bullets, demonstrated, rather than in a list of adjectives.
Example professional summary
Three or four lines, positioned for the role rather than describing your personality. Two versions you can adapt:
Business analyst with six years in general insurance and operations change. Work covers a claims intake redesign that removed 14 process steps and four handoffs, requirements for a policy amendment journey across three functions, and self-service SQL analysis that halved escalations on one product. BCS Diploma in Business Analysis.
Business analyst working in a hybrid delivery environment: process and requirements definition up front, story writing and refinement with the build team throughout. Comfortable querying the data myself rather than waiting for an extract.
Writing your experience
The difference between a CV that gets a call and one that does not is almost always in the bullet points. Each pair below shows a real rewrite of the kind of line that appears on most CVs in this field.
Weak
Gathered requirements from stakeholders.
Stronger
Ran nine elicitation workshops across claims, underwriting and compliance to define requirements for the new policy amendment journey, resolving a conflict between compliance record-keeping and the two-minute handling target.
Names the technique, the functions involved and the actual tension the analysis had to resolve.
Weak
Mapped business processes.
Stronger
Mapped the 41-step as-is claims intake process in BPMN and designed a to-be process with 27 steps, removing four handoffs between the contact centre and the back office.
Concrete before-and-after that anyone can evaluate, with a named notation.
Weak
Supported user acceptance testing.
Stronger
Wrote 130 UAT scenarios from the acceptance criteria and coordinated testing with 12 business users, logging 41 defects of which 9 were requirement gaps rather than build errors.
The honest split between build defects and requirement gaps shows real analytical maturity.
Weak
Analysed data to support decisions.
Stronger
Queried three years of complaint records in SQL and found that 62% of escalations came from one product variant with an ambiguous renewal notice; rewriting the notice reduced escalations on that product by around half.
Self-service data work leading to a specific, measurable fix.
Taken from the example
The sample CV for this profession is fully written. A few sections from it, so you can see the level of specificity that works:
Experience
Senior Business Analyst, Clydebank General Insurance
Mapped the 41-step as-is claims intake process in BPMN and designed a to-be process with 27 steps, removing four handoffs between the contact centre and the back office.
Ran nine elicitation workshops across claims, underwriting and compliance for the new policy amendment journey, resolving a conflict between compliance record-keeping and the two-minute handling target.
Queried three years of complaint records in SQL and found 62% of escalations came from one product variant with an ambiguous renewal notice; rewriting the notice halved escalations on that product.
Wrote 130 UAT scenarios and coordinated testing with 12 business users, logging 41 defects of which 9 were requirement gaps rather than build errors.
Projects
Claims intake redesign — As-is and to-be process modelling, requirements and UAT for the end-to-end claims intake journey.
Education
MA (Hons) Economics, University of Glasgow — Upper Second Class (2:1)
Certifications and registration
BCS International Diploma in Business Analysis — BCS
BCS Practitioner Certificate in Requirements Engineering — BCS
Common mistakes
Documentation as the achievement
"Produced business requirements documents" describes output, not outcome. What changed because the document existed?
No process detail
Process work is the most tangible thing a BA does. Give the number of steps, the handoffs removed, or the cycle time before and after.
Generic stakeholder language
"Liaised with stakeholders" is on every BA CV. Name the functions - operations, compliance, third-party supplier - and what the disagreement was about.
Being vague about the delivery method
Agile and waterfall BAs produce different artefacts. Employers filter on this, so say which you have worked in and be honest about the balance.
ATS considerations
Applicant tracking systems behave differently by sector, and generic advice is often wrong for a given field. These points are specific to business analyst applications:
Include "requirements gathering" and "requirements elicitation" both, since employers split between the two terms.
Spell out "user acceptance testing (UAT)" once so both forms match.
Name the notation - "BPMN 2.0" - rather than only "process mapping".
List SQL if you have it; it is a genuine differentiator and frequently a stated requirement.
The Minimal ATS layout is built for this, and the ATS guide covers what parsers do to a file in more detail.
Questions about business analyst CVs
Do I need the BCS Diploma?
It is widely recognised in the UK and often listed as desirable rather than essential. It helps most when moving between industries, where domain experience does not transfer as easily.
How much technical knowledge do I need?
Enough to have a useful conversation with developers about feasibility and data. SQL, an understanding of APIs and familiarity with system integration patterns cover most BA roles.
What is the difference between a business analyst and a product owner?
A product owner is accountable for what gets built and in what order; a BA is accountable for the analysis that makes those decisions sound. In smaller teams the same person often does both, and the CV should say so.
How do I move into business analysis from an operational role?
Domain knowledge is genuinely valuable, so lead with it. Then show the analysis you already do: process improvement, reporting, testing and requirements for changes to your own systems.