The 90-Day IT Readiness Plan for a New China WFOE

The short answer: A new China WFOE's IT readiness runs on a 90-day clock with four distinct phases: what you can set up before your entity and bank account exist, days 1-30 (network, helpdesk, baseline security), days 31-60 (cloud/M365 cross-border setup and MLPS scheduling), and days 61-90 (PIPL review and your first compliance audit). This guide covers the operational timeline; a separate guide covers the narrower question of procuring hardware before your entity exists.

Opening a new WFOE (wholly foreign-owned enterprise) in China puts IT on the critical path whether anyone planned for that or not. Employees need laptops and network access on their first day in the office; HQ needs a working helpdesk before the first support ticket ever gets filed; and two regulatory regimes — MLPS (等保) classification and PIPL's data-handling rules — start their clocks the moment you have systems and personal data in mainland China, not the moment you feel ready to deal with them. Most IT leaders planning a China office focus on a single milestone — "get the network up" — and then discover, weeks later, that helpdesk coverage, security baselines, cloud tenancy and compliance filings were all supposed to happen on overlapping timelines they never mapped out.

This guide lays out that timeline as a 90-day plan, broken into the phase before your entity and bank account exist, and then three 30-day bands after your WFOE is live. It is deliberately scoped to the *operational readiness* question — what gets stood up, in what order, and who owns each milestone — rather than the narrower question of how you physically procure laptops and network equipment before your entity can legally purchase anything. That procurement question has its own mechanics (domestic supplier requirements, fapiao, device-as-a-service structures) and its own dedicated guide: procuring IT hardware for a new China office before your entity and bank account exist. Read that one alongside this guide if you are still pre-entity — this guide picks up the broader readiness plan around it rather than repeating it.

This plan tends to matter most in three recurring situations: a global IT leader has just been told a China WFOE will open in a fixed window and needs a realistic build-out timeline to hand to HQ; a compliance or legal team has asked, mid-registration, exactly when MLPS filing and PIPL review actually need to happen relative to entity approval; or an office has already opened without a plan, IT is being assembled reactively, and someone wants to know how far behind a "normal" build-out they actually are. Each of those starting points benefits from the same structure — a fixed sequence of phases with named owners — rather than a single "stand up IT" line item that quietly swallows everything from cabling to compliance filings into one undifferentiated task.

What's Already Possible Before Your Entity and Bank Account Exist?

WFOE registration and bank account opening in China commonly take anywhere from six to twelve weeks once documentation is in order, and delays are common. Waiting for that process to finish before starting any IT planning wastes most of your runway to day one. A meaningful amount of groundwork can, and should, happen in parallel:

• Scoping and design work. Network topology, wireless site survey requirements, helpdesk staffing model, and a first-pass MLPS system inventory can all be planned against your lease and headcount projections without needing a bank account.
• Contracting through your existing entity. Many multinationals can sign a preliminary services agreement through their Hong Kong or overseas entity while their mainland delivery partner's China-registered entity is still being finalized in the contract paperwork — see the FAQ below on contracting mechanics.
• Interim hardware procurement. Laptops, network gear and initial cloud accounts can move through a domestic partner acting as a procurement and deployment bridge, which is exactly what our hardware-procurement guide walks through in detail.
• What genuinely has to wait. Anything that requires your WFOE's own fapiao-issuing capability — direct contracts invoiced to your China entity, MLPS filing under your entity's name with local public security authorities, and opening accounts that require a business license — cannot happen until registration and the bank account clear.

Treat the pre-entity phase as design and staging, not deployment. The goal is to walk into day one of registration with a network design, a vendor relationship, and hardware already staged, rather than starting the search for an IT partner after the lease is signed. Offices that skip this staging step tend to compress everything into the first 30 days after registration instead — trying to design, procure and deploy simultaneously under the pressure of new hires already showing up for work, which is exactly the crunch a 90-day plan is meant to avoid.

Days 1-30: Network, Helpdesk and Baseline Security

The first 30 days after your entity is live (or after your office physically opens, if that happens first) are about getting people connected and supported, not about getting everything perfect. Priorities in this window:

• Physical network installation. Structured cabling, Wi-Fi access points sized to the floor plan via a proper wireless site survey, and firewall/router deployment through IT infrastructure deployment services. Leased-line or dedicated internet circuits in China often have multi-week lead times, so this should be ordered the moment the entity can contract for it — sometimes with a temporary 4G/5G backup circuit bridging the gap.
• Helpdesk stand-up. A working ticketing system, a local support phone number or chat channel, and defined response-time expectations need to exist before your first new hire's first laptop problem, not after. This is where 24/7 help desk IT support gets configured and tested against your actual user list.
• Baseline security. Endpoint protection, patch management, MFA on core accounts, and a documented (even if minimal) acceptable-use policy — the floor, not the ceiling, of managed IT security services. This baseline exists so that whatever comes next in days 31-90 is built on something defensible, not bolted onto an unmanaged environment.
• Device provisioning for early hires. Whoever is already on the ground — often a small advance team — gets working, secured devices from day one rather than waiting for the full headcount to arrive before IT "really" starts.

By day 30, the honest goal is a working, monitored, supportable environment for whoever is in the office — not a fully mature compliance posture. That comes next. It is worth resisting the temptation to declare victory at day 30 just because people can log in and print — a network that works but has no monitoring, no patch cadence and no documented baseline is a liability wearing the appearance of progress, and it makes days 31-90 considerably harder to build on cleanly.

Days 31-60: Cloud, M365 Cross-Border Setup and MLPS Scheduling

With connectivity and helpdesk running, days 31-60 shift toward the systems and compliance work that take longer to stand up correctly:

• Cloud tenancy and identity. Microsoft 365 or Google Workspace tenant configuration, single sign-on, and email migration or provisioning for the China office, built through managed IT and cloud services. Cross-border considerations matter here — where mailboxes and files are hosted, and how that interacts with PIPL, should be decided deliberately rather than defaulted to whatever configuration was fastest to click through.
• MLPS classification triage. Formal MLPS (等保) filing cannot happen until your entity legally exists and can file under its own name, but days 31-60 is the window to inventory which systems will fall in scope, do a preliminary risk-level self-assessment, and engage a qualified third-party assessor to schedule the formal classification and assessment process. Filing and assessment for a new system typically runs several weeks once scoping and documentation are in order — start scheduling early rather than treating it as a day-90 task.
• Backup, disaster recovery and VPN. Backup policies, recovery point objectives, and secure remote-access VPN configuration should be running and tested — not just configured — by the end of this window, through cloud managed backup.
• Security policy documentation. Formalizing the baseline security controls from days 1-30 into written policy gives you something to hand to an MLPS assessor or a PIPL reviewer later, rather than reconstructing it retroactively under deadline pressure.

This is also typically when a full-time or near-full-time on-site presence starts to matter more, whether that is an internal hire settling into the role or full-time on-site IT support services covering the gap while you build toward one. Vendor-side scheduling matters here too: qualified MLPS assessors and third-party auditors often carry their own booking lead times independent of your own readiness, so initiating that conversation early in this window — even before your systems are fully configured — tends to save real calendar weeks later in the plan.

Days 61-90: PIPL Review and Your First Compliance Audit

The final third of the 90-day window is where compliance moves from "scheduled" to "reviewed":

• PIPL data-flow mapping. Document what personal information your China systems collect, where it is stored, who can access it, and whether any of it crosses out of mainland China — to HQ reporting systems, a group-wide CRM, or overseas backup storage. Cross-border transfers of personal information carry specific PIPL requirements, in some cases including a security assessment, and this is the window to map that exposure honestly rather than discover it during an audit.
• Consent-mechanism review. Confirm that however your systems collect employee or customer personal information, the consent language and mechanism actually meet PIPL's requirements, rather than reusing a privacy notice written for a different jurisdiction.
• First internal security review or MLPS assessment checkpoint. Whether your formal MLPS assessment has completed by day 90 or is still in progress (entirely normal, given typical assessment timelines), days 61-90 should include an internal walkthrough of what the assessor will actually check, so gaps surface on your own schedule rather than the assessor's.
• Incident-response tabletop. A short, practical walkthrough of "what do we actually do if a laptop is stolen, a phishing email lands, or a vendor reports a breach" — tested once before you need it for real, not left as an untested policy document.
• 90-day retrospective. A short internal review against the plan you started with: what shipped on time, what slipped, and what the steady-state ownership model looks like now that the initial build-out is behind you.

Reaching day 90 with a documented, reviewed environment — even if some MLPS paperwork is still working through the assessor's calendar — is a materially stronger position than reaching day 90 having never mapped the compliance exposure at all. Treat day 90 as a checkpoint rather than a finish line: MLPS assessments recur, PIPL obligations apply for as long as you process personal information in mainland China, and the environment you built in the first 90 days is the foundation the next twelve months of operation and audits will sit on.

Who Owns Each Milestone?

The single most common failure mode in a 90-day plan is not a missed technical step — it is an unassigned owner discovered only when something is already late. Assign ownership explicitly, in writing, before day one:

• Pre-entity scoping and vendor contracting — usually HQ IT leadership or a regional IT manager, working with legal on the interim contracting mechanism.
• Network and physical infrastructure (days 1-30) — typically the IT services vendor under a statement of work, with a named local point of contact for on-site coordination.
• Helpdesk and device provisioning (days 1-30) — vendor-owned under fully managed, or jointly owned with an internal hire under co-managed, but never left ambiguous between the two.
• Cloud/M365 configuration and MLPS scheduling (days 31-60) — vendor technical lead, with sign-off from whoever owns data governance at HQ, since cross-border cloud decisions have compliance implications beyond IT.
• MLPS classification and filing, PIPL review (days 61-90) — this is the ownership question that most often gets left unstated. Under fully managed, the provider's China-registered entity typically takes this on as contracted scope; under co-managed or in-house, it must be explicitly assigned to someone, internal or external, since generalist IT staff rarely arrive already knowing MLPS filing mechanics.
• The 90-day retrospective and steady-state handover — HQ IT leadership, reviewing against the original plan with whoever executed it.

Write this ownership list down and revisit it at each 30-day mark, not just at the end. A milestone with no named owner is not actually on the plan, whatever the project spreadsheet says.

DIY/In-House vs. Fully Managed vs. Co-Managed for the 90-Day Window

How you staff this 90-day build-out shapes how fast it goes and how much compliance risk lands entirely on your own team:

• DIY/In-House Only — you hire (or task an existing employee with) building the entire environment from scratch; full control over every decision, but the 90-day clock is competing against recruiting timelines, and a single hire handling network setup, helpdesk stand-up and MLPS scheduling simultaneously is a realistic bottleneck, not a hypothetical one — most in-house teams have never run an MLPS filing before and are learning it live under deadline.
• Fully Managed — a single provider with a China-registered entity runs network deployment, helpdesk, security baseline and MLPS/PIPL compliance scheduling as one contracted scope from day one; fastest realistic path to a working, compliant environment inside 90 days, since the provider has already run this exact 90-day sequence for other new offices and is not building the playbook from scratch.
• Co-Managed — you bring in (or already have) an internal hire who owns strategic decisions and day-to-day priorities, with a partner executing the parts that do not scale to one person in 90 days — physical deployment, after-hours helpdesk coverage, and MLPS/PIPL filing mechanics — under a scoped agreement; works well when you already have, or are actively hiring, a trusted local IT lead and want the 90-day build-out to hand off cleanly to them at day 90 rather than restart under a different team.

None of the three is universally "faster" — DIY is fastest only if you already have the right person in seat on day one, which is rarely true for a brand-new office. For most new WFOEs without an existing local IT hire already in place, fully managed or co-managed compresses the 90-day timeline the most, because the provider is executing a sequence it has already run before rather than assembling it from scratch under deadline pressure.

Frequently Asked Questions

Is it realistic to have IT infrastructure fully ready before our WFOE is officially approved?

Partially, and that is the honest answer. Design work, vendor selection, contracting through your existing overseas entity, and interim hardware procurement through a domestic partner bridge can all happen before your WFOE and bank account exist — see our hardware procurement guide for how that bridge typically works. What cannot happen pre-entity is anything requiring your WFOE's own fapiao capability or filings made in your entity's name, including formal MLPS registration. Plan for a staged handoff rather than a single go-live moment.

How long does MLPS classification and filing typically take within the 90-day window?

Formal filing under your own entity's name cannot begin until your WFOE is registered, so the realistic window is roughly days 31 through 90 — scoping and a preliminary self-assessment in days 31-60, and formal classification, filing and the start of the assessment process in days 61-90. Higher-graded systems then carry an ongoing annual assessment cadence afterward, so treat day 90 as the start of a recurring compliance obligation, not a one-time finish line. Assessment timelines vary by locality and assessor availability, so build in buffer rather than assuming day 90 is a hard deadline.

Can we sign an IT services contract through our Hong Kong entity before Brocent's mainland entity (博迅) is formally engaged?

Yes — this is a common and workable structure. A preliminary services agreement can be executed through your Hong Kong or regional entity to lock in scope, pricing and a start date while the delivery details under the mainland-registered entity are finalized, with the contract transitioning to (or being supplemented by) the mainland entity once it is ready to invoice and file locally with proper fapiao. Confirm explicitly, in writing, which entity holds which responsibilities and at what point the transition happens, rather than assuming it is automatic.

What's the actual difference between this plan and the hardware procurement guide?

This guide covers the full 90-day operational build-out — network, helpdesk, security baseline, cloud/M365 setup, and the MLPS/PIPL compliance timeline. The hardware procurement guide answers one narrower, earlier question inside that timeline: how do you physically buy laptops, network equipment and cloud licenses when your entity and bank account do not exist yet to legally purchase anything. Read the procurement guide as the pre-entity chapter of this broader plan, not as a competing or separate roadmap.

What happens if entity registration is delayed and pushes our whole plan past day 60 or day 90?

Delays in WFOE registration and bank account opening are common enough that your 90-day plan should be built around milestones relative to entity registration, not fixed calendar dates. If registration slips, the pre-entity design and staging work should already be complete, which means days 1-30 can compress once the entity clears, rather than starting from zero. Build a buffer into your MLPS and PIPL timelines specifically, since those depend on external assessor scheduling that you do not fully control, and communicate the revised milestone dates to HQ stakeholders as soon as a slip is confirmed rather than waiting until a deadline is missed.

Building Your Own 90-Day Plan

A 90-day IT readiness plan works because it forces four separate questions — what can happen before the entity exists, what gets built in the first 30 days, what compliance and cloud work needs days 31-60, and what needs formal review by day 90 — into a sequence with named owners, instead of one vague "get IT running" goal that quietly absorbs every other priority. The specific milestones will shift with your headcount, industry, and how many systems fall inside MLPS scope, but the four-phase structure holds across nearly every new China WFOE we have supported. If you want help mapping this plan against your specific timeline, headcount and entity-registration status, get in touch and we can walk through what your first 90 days should actually look like.