Data Security in Outsourcing: How to Protect Your Data When You Outsource Software Development

Data security in outsourcing means keeping your customer data, source code and credentials protected while an external team builds or runs your software. You achieve it in four layers: choose a vendor whose security you can verify (for example, an ISO/IEC 27001 certified management system), put data protection duties in the contract, give the team only the access and data it needs through controlled environments, and monitor and end the relationship in a way that returns or deletes everything. The risk is real: Verizon’s 2025 Data Breach Investigations Report found that third-party involvement in breaches doubled to 30%. Outsourcing does not have to raise your risk, but unmanaged outsourcing does.

Why data security matters more when you outsource

When you outsource software development, more people, devices, networks and tools touch your systems. Each is a potential entry point. The 2025 Verizon DBIR, which analyzed over 22,000 security incidents including 12,195 confirmed data breaches, reported that third-party involvement in breaches has doubled to 30%. The same report found ransomware present in 44% of breaches, with credential abuse (22%) and exploitation of vulnerabilities (20%) among the leading initial attack vectors. Development teams handle exactly those things: credentials, servers and code that may contain vulnerabilities.

The cost of getting it wrong is high. IBM’s 2025 Cost of a Data Breach Report put the global average cost of a data breach at $4.44 million, and the average in the United States at a record $10.22 million. Healthcare breaches averaged $7.42 million, the most expensive of all industries studied. The average breach lifecycle (the time to identify and contain a breach) was 241 days.

None of this means outsourcing is unsafe. A mature vendor may run better security than a small in-house team, because it has to pass client audits and certification every year. The point is that security has to be designed into the relationship, not assumed. If you are still deciding whether to outsource at all, our comparison of in-house vs outsourcing software development covers the wider trade-offs.

The main data risks when outsourcing software development

The original four risks of outsourcing (unauthorized access, data theft and breaches, loss of data control, and regulatory violations) still apply. In 2026 they have grown three companions: supply chain risk in code, AI tool leakage, and weak offboarding.

1. Unauthorized access

Vendor staff receive accounts on your repositories, cloud consoles, databases and admin panels. Shared accounts, over-broad permissions and accounts that are never removed are the most common weaknesses. A single stolen developer credential with production access can expose an entire customer database.

2. Data theft and breaches

Attackers target vendors because one vendor can open the door to many clients. A breach can start with a phishing email to a vendor employee, a laptop without disk encryption, or a test database copied to an unsecured server. Indirect attacks of this kind are what the DBIR’s 30% figure describes.

3. Loss of data control

Without clear rules, copies of your data spread: exported spreadsheets, local test databases, chat attachments, backups in the vendor’s cloud account. When the project ends, nobody can say where all the copies are. Dependence on a single vendor who holds credentials, infrastructure and knowledge also reduces your control.

4. Regulatory violations

If your vendor mishandles personal data, regulators and customers hold you responsible. Cross-border data flows (for example, a Japanese company working with a team in Vietnam) bring the rules of more than one country into play.

5. Software supply chain risk

Vendors pull in open-source libraries, build tools and third-party services. A vulnerable or malicious dependency, an exposed API key committed to a repository, or an unpatched framework becomes your vulnerability once it ships.

6. AI tools and shadow AI

Developers increasingly paste code, logs and data into AI assistants. If those tools are not approved and configured, your source code or customer data can leave your control. IBM’s 2025 research found that one in five organizations reported a breach due to shadow AI, and only 37% have policies to manage AI or detect shadow AI. High levels of shadow AI added an average of $670,000 to breach costs. Of the 13% of organizations that reported breaches of AI models or applications, 97% said they had no AI access controls in place.

7. Weak offboarding

Team members rotate off the project, and eventually the contract ends. Accounts that stay active, data that is never deleted and knowledge that leaves with the vendor are risks that appear months after anyone is looking.

Risk	Typical root cause	Example impact	Main control
Unauthorized access	Shared or over-privileged accounts	Customer database exposed	Named accounts, least privilege, MFA
Data theft and breaches	Phishing, unmanaged devices, copied test data	Personal data leak, ransom demand	Managed devices, masked data, monitoring
Loss of data control	No data inventory or transfer rules	Untraceable copies after project end	Data handling policy, client-owned infrastructure
Regulatory violations	No processing agreement, unlawful transfer	Fines, mandatory notifications	DPA, transfer assessment, vendor supervision
Supply chain	Vulnerable dependencies, secrets in code	Exploitable production system	Dependency scanning, secret scanning, code review
Shadow AI	Unapproved AI tools	Source code or data leakage	AI usage policy, approved tools, access controls
Weak offboarding	No exit procedure	Former staff retain access	Exit checklist with evidence

Who is responsible: client, vendor or both?

Responsibility is shared, but accountability stays with the data owner. Most data protection laws distinguish the organization that decides why and how data is processed (the controller or data owner) from the organization that processes it on their behalf (the processor or entrusted party). Your software vendor is usually the second.

Area	Client (data owner)	Vendor (processor)
Deciding what data is collected and why	Owns	Advises
Choosing a vendor with adequate security	Owns	Provides evidence
Contract and data processing terms	Owns, negotiates	Agrees, complies
Access approval	Approves	Requests, uses minimum needed
Secure development practices	Sets requirements	Implements
Staff screening, NDAs, training	Verifies	Owns
Incident detection and notification	Notifies regulators and users	Detects, reports to client promptly
Data return and deletion at the end	Requests, verifies	Executes, provides evidence

Step 1: Choose a vendor whose security you can verify

Security claims on a website cost nothing. Ask for evidence.

Certifications and what they prove

ISO/IEC 27001 is the international standard that defines the requirements an information security management system (ISMS) must meet. The current edition was published in 2022 and amended in 2024. A certificate shows that an independent auditor has checked that the vendor runs a managed system of risk assessment and controls. Ask for the certificate, its scope (does it cover the office and team that will work on your project?) and its expiry date.

SOC 2 reports, common with US vendors, describe controls over security, availability, processing integrity, confidentiality and privacy. A Type II report covers how controls operated over a period, which is stronger evidence than a Type I report on design at a point in time. Industry rules may add requirements, such as PCI DSS if the vendor will touch payment card data.

Vendor security questionnaire

Area	Question to ask	Good answer looks like
Governance	Who is responsible for information security, and how often are policies reviewed?	A named security lead; policies reviewed at least annually
Certification	Which certifications do you hold, and what is the scope?	Current certificate whose scope includes the delivery team
People	Do staff sign NDAs and receive security training?	NDA for every employee; onboarding and yearly training
Devices	Are laptops company-managed, encrypted and patched?	Managed devices, disk encryption, endpoint protection
Access	How do you grant and remove access to client systems?	Named accounts, MFA, approval workflow, same-day removal
Development	What secure coding practices do you follow?	Code review, dependency and secret scanning, OWASP guidance
Incidents	What happens if you detect a breach affecting us?	Documented incident response with a client notification time
Sub-contractors	Do you use subcontractors or freelancers?	Only with written client approval
AI tools	Which AI tools may developers use on client code?	Approved list, enterprise settings, client opt-out respected
Exit	How do you return and delete data when the project ends?	Written procedure with deletion confirmation

Red flags

• No certification and no ability to describe controls concretely.
• Developers work on personal laptops or from shared accounts.
• The vendor asks for a full copy of your production database “to test properly”.
• Reluctance to accept audit rights or breach notification terms.
• Unclear answers on whether freelancers or partner companies will join the project.

For a full partner selection process beyond security, see our guide on how to choose a software development company.

Step 2: Put data protection into the contract

A comprehensive written agreement is the foundation of data security in outsourcing. It defines how data may be used, shared and transferred, and what happens when something goes wrong. Most projects combine a master services agreement, an NDA and a data processing agreement (DPA).

If EU personal data is involved, GDPR sets the minimum content. Article 28 of the GDPR requires controllers to use only processors that provide “sufficient guarantees” of appropriate technical and organisational measures. The contract must require the processor to act only on documented instructions, bind its staff to confidentiality, take the security measures in Article 32, engage sub-processors only with prior written authorisation, help the controller respond to data subject requests and meet breach and impact assessment duties, delete or return all personal data at the end, and allow audits and inspections. That list is a good template even when GDPR does not apply.

Security clauses to include

Clause	What it should say
Purpose limitation	Data is used only to perform the agreed services, on documented instructions
Security standard	Vendor maintains an ISMS (ISO/IEC 27001 or equivalent) and the controls listed in a security annex
Confidentiality	All staff with access are bound by confidentiality and receive security training
Sub-processors	No subcontractors or freelancers without prior written approval
Data location and transfer	Where data may be stored and processed; transfers only as permitted by law
Breach notification	Vendor notifies the client without undue delay, within an agreed number of hours, with the facts needed for regulatory reports
Audit rights	Client may audit, or receive independent audit reports, on reasonable notice
AI tool use	Which AI tools may process client code or data, and with what settings
Intellectual property	Source code, documentation and credentials belong to the client
Return and deletion	At the end, all client data is returned or deleted, with written confirmation
Liability	Allocation of costs and liability for breaches caused by either party

Set the breach notification window with your own regulatory deadline in mind. GDPR, for example, expects controllers to notify the supervisory authority within 72 hours of becoming aware of a breach where feasible, so a vendor clause that allows a week is not compatible. For engagement models, pricing and other contract terms, see our guide to offshore software development services.

This section is general information, not legal advice. Have a lawyer review your contract for the jurisdictions involved.

Step 3: Implement technical security controls

Contracts set expectations; controls make them real. The following measures prevent most outsourcing incidents and are standard practice for a mature vendor.

Identity and access

• Named accounts only. Every person has their own account in every system. No shared logins.
• Multi-factor authentication on source control, cloud consoles, VPN, email and admin panels.
• Least privilege. Developers get access to development and staging; production access is limited to the few people who need it, ideally through just-in-time elevation that expires.
• Single sign-on where possible, so removing one identity removes access everywhere.
• Quarterly access reviews in which the client confirms the list of people with access.

Data handling

• Keep production data in production. Use synthetic or masked data for development and testing. If real data is unavoidable for a bug investigation, use a controlled, logged and time-limited process.
• Encryption in transit (TLS) and at rest for databases, storage buckets, backups and laptops.
• Data minimization. Collect and keep only the personal data the product needs; it reduces both breach impact and compliance scope.
• Secrets management. API keys and passwords live in a secrets manager, never in code, tickets or chat.

Environments and devices

• Client-owned infrastructure. Repositories, cloud accounts and domains are registered to the client, with the vendor invited as a user. This keeps control on your side if the relationship ends.
• Separate environments for development, staging and production, with different credentials.
• Managed devices with disk encryption, screen lock, endpoint protection and automatic updates.
• Network controls such as VPN or zero-trust access for sensitive systems.

Secure development

• Code review on every change, with security items in the review checklist.
• Automated scanning in CI: static analysis, dependency vulnerability scanning and secret scanning, with builds blocked on critical findings.
• OWASP guidance for common web risks such as broken access control and injection.
• Penetration testing before major releases and at least yearly for high-risk systems.
• Logging and monitoring of authentication, admin actions and data exports, with alerts on anomalies.

AI tool governance

• Agree which AI coding assistants are allowed and under which account type and settings.
• Prohibit pasting customer data, credentials or confidential logs into AI tools.
• Apply the same review and scanning to AI-generated code as to human-written code.
• Restrict access to any AI features or models you build, the gap IBM’s research found in 97% of breached AI systems.

Automation pays off. IBM’s 2025 report estimates cost savings of $1.93 million for organizations making extensive use of AI and automation in security, compared with those using none.

Step 4: Meet data protection laws across borders

Outsourcing often moves data between countries. The rules of the country where your users live usually follow the data. Here are the three frameworks most relevant to Japanese and global clients working with Vietnamese development teams.

Law	Who it protects	Key duties for outsourcing	Source
GDPR (EU)	Individuals in the EU	Processor contract (Art. 28), security of processing (Art. 32), breach notification, rules on transfers outside the EU	EUR-Lex
APPI (Japan)	Individuals whose data Japanese businesses handle	Supervise entrusted parties (Art. 25), report leaks to the PPC (Art. 26), restrictions on provision to third parties in foreign countries (Art. 28)	Japanese Law Translation
Personal Data Protection Law 91/2025/QH15 (Vietnam)	Personal data processed in or linked to Vietnam	Duties for controllers and processors, cross-border transfer rules, fines	Ha Tinh provincial government

Japan: supervise the entrusted party

Japan’s Act on the Protection of Personal Information is explicit about outsourcing. Article 25 states that if a business entrusts another person with all or part of the handling of personal data, “it must exercise the necessary and adequate supervision over the person it entrusts.” In practice, that means selecting a vendor with appropriate safeguards, signing a contract that sets data handling rules, and checking how the vendor actually handles the data. Article 26 requires businesses to report leaks likely to harm individuals to the Personal Information Protection Commission, so your vendor’s notification clause must give you the facts in time.

Vietnam: a new data protection law since 2026

Vietnam’s Personal Data Protection Law (Law No. 91/2025/QH15) took effect on 1 January 2026. It sets duties for data controllers and processors and introduces significant fines: up to 5% of the previous year’s revenue for violations of cross-border transfer rules, up to 10 times the income gained from buying or selling personal data, and up to 3 billion VND for other violations by organizations. For clients outsourcing to Vietnam, it means a Vietnamese vendor now works under its own national data protection regime in addition to your contract and your home country’s law.

Practical compliance steps

1. Map which personal data the vendor will access, from which countries.
2. Decide whether the vendor needs personal data at all, or whether masked data is enough.
3. Sign a DPA that meets the strictest applicable law.
4. Document the legal basis for any cross-border transfer.
5. Agree a breach notification time short enough for your regulatory deadlines.
6. Keep records of supervision: questionnaires, audit reports, access reviews.

Step 5: Train people and build a security culture

Most breaches involve a human step: a clicked link, a reused password, a file sent to the wrong place. Training is not a one-time slide deck.

• Onboarding: every new team member learns the client’s data rules, the approved tools and how to report a concern before getting access.
• Regular refreshers: at least yearly, with short updates when threats or rules change.
• Phishing simulations for both client and vendor staff.
• Easy reporting: make it simple and blame-free to report a suspected incident or mistake. Early reports limit damage.
• Shared responsibility: train in-house staff too. Many incidents start with a client employee emailing a database export to the vendor “to save time”.

Step 6: Monitor, audit and respond to incidents

Security in an outsourcing relationship is a continuous process. Plan these activities into the engagement from the start.

Activity	Frequency	Owner	Evidence
Access review	Quarterly and on team changes	Client approves, vendor prepares	Signed access list
Dependency and secret scanning	Every build	Vendor	CI reports
Security review of major features	Per release	Vendor tech lead	Review notes
Penetration test	Yearly or before major launches	Client commissions	Test report and fixes
Vendor security questionnaire refresh	Yearly	Client	Completed questionnaire
Certification check	Yearly	Client	Current certificate
Incident response drill	Yearly	Both	Drill notes and actions

Incident response in an outsourced project

1. Detect and report: whoever detects the issue reports it through the agreed channel immediately.
2. Contain: revoke compromised credentials, isolate affected systems, preserve logs.
3. Assess: what data, how many people, which jurisdictions.
4. Notify: the client notifies regulators and affected users as required; the vendor supplies the facts.
5. Fix: remove the cause, patch, rotate secrets.
6. Learn: run a blameless review and update controls and the contract annex.

Step 7: Offboard securely

The end of a project, or a change of team members, is where data security in outsourcing most often fails. Prepare the exit procedure at the start.

Task	Responsible	Evidence
Revoke all accounts (source control, cloud, SSO, VPN, tools, chat)	Client, with vendor list	Access report showing removal
Rotate shared secrets and API keys the vendor knew	Client or new team	Rotation log
Transfer repositories, documentation and infrastructure ownership	Vendor	Handover checklist signed
Return or delete all client data, including backups and local copies	Vendor	Written deletion confirmation
Recover or wipe devices used only for the project	Vendor	Device log
Confirm ongoing confidentiality duties	Both	Contract clause reference

If you are changing vendors rather than ending the project, read our guide on changing development team members while improving apps for the handover side.

Match controls to the type of data

Not every project needs the same level of protection. Classify the data the vendor will touch, then scale the controls. A marketing website and a payment platform should not share one security plan.

Data type	Examples	Minimum controls when outsourcing
Public or low sensitivity	Marketing content, public product catalog	Named accounts, MFA on source control and hosting
Internal business data	Sales reports, internal documents, configuration	Least privilege, NDA, client-owned repositories, access reviews
Personal data	Customer names, contact details, purchase history, employee records	DPA, masked test data, encryption, logging, breach notification clause, cross-border transfer check
Special or high-risk personal data	Health information, data about children, precise location	All of the above plus restricted production access, data protection impact assessment, stricter retention rules
Payment data	Card numbers, bank details	Use a certified payment provider so card data never touches your code; PCI DSS scope review
Source code and IP	Algorithms, unreleased features	IP clause, repository ownership, AI tool policy, secret scanning
Credentials and keys	API keys, database passwords, signing certificates	Secrets manager, rotation on team changes, no sharing in chat or tickets

Common mistakes clients make

Vendors are not the only source of risk. These client-side habits cause many of the incidents in outsourced projects:

• Sending a full production database export by email or chat so the vendor can “reproduce a bug”. Agree a masked data process instead.
• Creating the cloud account in the vendor’s name to start faster, then struggling to take ownership later.
• Sharing one admin login with the whole vendor team, which makes it impossible to see who did what or to remove one person.
• Skipping the DPA because “it is only a development project”, even though the team will see real personal data.
• Never reviewing access after the first month, so people who left the project years ago still have accounts.
• Treating security as the vendor’s job alone. Accountability for personal data stays with you under the APPI, GDPR and Vietnam’s new law.

Data security across the outsourcing lifecycle

Phase	Key actions
Before selection	Classify your data; decide what the vendor really needs to see
Vendor selection	Check certification scope, run the questionnaire, look for red flags
Contract	DPA, security annex, breach notification, audit rights, AI tools, exit terms
Onboarding	Named accounts, MFA, least privilege, training, client-owned infrastructure
Delivery	Masked test data, code review, scanning, logging, quarterly access reviews
Incidents	Agreed reporting channel, containment, notification, blameless review
Exit	Revoke access, rotate secrets, transfer ownership, delete data with evidence

How SupremeTech protects client data

SupremeTech is a custom software development company based in Da Nang, Vietnam, with a presence in Tokyo. We hold ISO/IEC 27001 certification for our information security management system, and we have delivered multi-million-user products for Japanese corporations, where security expectations are high.

A good example is our SmartHR integration for a health management system. A Japanese healthcare technology company needed its enterprise health app to sync employee master data from SmartHR, an HR platform: new employees, profile changes, role changes and leavers. Employee HR data is exactly the kind of data that needs careful handling. The team built the connection on SmartHR OAuth 2.0 for authentication, with data access through protected access tokens and a governed integration flow that combines webhook updates with batch reconciliation through SmartHR’s export API. The integration runs in production, and the health app is listed on SmartHR Plus.

Scale brings its own security demands. Our work on one of Japan’s largest dating apps, which serves tens of millions of users, required strong security measures across web, admin and mobile apps.

[SupremeTech detail: 2 to 3 concrete ISMS practices the delivery team follows day to day, for example device policy, access approval flow, data masking rule or AI tool policy]

Communication is a security control too. Our business analysts speak Japanese and join requirement meetings with clients directly, which reduces misunderstandings about what data may be used and how. With Da Nang only two hours behind Tokyo, incident calls and access approvals can happen within the same working day.

To discuss a project with security requirements, explore our custom software development services.

Data security checklist for outsourcing

• We know what data the vendor will access, and we have removed what it does not need.
• The vendor’s ISO/IEC 27001 (or equivalent) certificate is current and covers the delivery team.
• We have a signed NDA, DPA and security annex.
• Subcontractors require our written approval.
• Breach notification time fits our regulatory deadlines.
• Every person has a named account with MFA.
• Production access is limited and logged.
• Development and testing use masked or synthetic data.
• Secrets live in a secrets manager.
• Repositories and cloud accounts are owned by us.
• CI runs dependency and secret scanning.
• We have an agreed AI tool policy.
• Access reviews happen quarterly.
• We have tested the incident response process together.
• The exit procedure, including data deletion evidence, is written down.

Conclusion

Data security in outsourcing is a process, not a promise. Verify the vendor before you sign, write data protection duties into the contract, give the team the minimum data and access it needs, monitor continuously and plan the exit from the start. Third-party breaches are rising, but a well-run outsourcing relationship can raise your security level rather than lower it.

Frequently Asked Questions