Direct answer: An information-security and customer data-exchange page cannot just say "we value information security and sign NDAs." It should state how customer/supplier data is classified, who can access it, how it is transmitted and stored, how subcontractors/cloud/AI tools are controlled, how a breach is detected/notified/handled, how data is returned/deleted at the end, how security questionnaires/certifications are answered, how cross-border transfer is handled, and what must not be published. Otherwise, when a customer asks "where is our drawing stored, who can see it, how fast do you notify a breach, will you delete it after the project, do you have ISO 27001," the answer becomes an ad-hoc explanation.
This guide is for IT, quality, procurement, legal, sales and website teams at manufacturers in Changzhou and nearby industrial areas. It explains how to build and accept an information-security and customer data-exchange page. Information is current to 2026-11-02. It is a review of public regulations and project practice, not cybersecurity, data-compliance, certification or legal advice; specific classification, access, incident notification, cross-border and contract requirements depend on applicable law, the customer contract/security questionnaire and company policy.
Information security is not "we have an NDA/certificate": it is lifecycle management—classification, access, transmission, storage, subcontractors, incidents and deletion. Customer drawings, BOMs, prices, personal information and important data need different protection; personal chat apps/public cloud drives for customer data are a common high risk. A breach must be handled immediately and notified per contract/law—not hidden; at project end, data must be returned/deleted with evidence.
How does the infosec page relate to technical-data/NDA, PIPL and website-security pages?
The technical-data/drawing page answers "how data is classified, NDA, watermark, version, download logs"; the PIPL page answers "personal-information compliance audit for website forms/CRM/AI customer service"; the Cybersecurity Law page answers "website/log/AI cybersecurity duties"; the infosec/data-exchange page answers "how customer/supplier data is protected from receipt to deletion, how incidents are handled, how security questionnaires are answered." The technical-data page is "how to give the drawing"; the infosec page is "how to manage it after it is given/received."
The common break is: customer drawings sit on a public cloud drive/personal chat app, and ex-employees can still access them; a supplier/subcontractor forwards drawings to a second-tier subcontractor without flow-down; cloud/mail accounts are shared without MFA; a customer security questionnaire is filled by sales "by eye" and does not match reality; a breach is handled internally without notifying the customer; at project end only local files are deleted while backups/shared links remain; an AI tool uploads customer drawings/personal information directly. A page that states classification, access, transmission, subcontracting, incidents, deletion, questionnaires and cross-border gives IT, quality, procurement and legal one playbook.
| Page/entry | Answers | Audience | Cannot replace |
|---|---|---|---|
| Technical data/drawings | Classification, NDA, watermark, version, download logs | Customer, sales, IT | Full lifecycle security |
| Infosec/data exchange | Access, transmission, incidents, return/delete, questionnaires | Customer, IT, legal | Contract/security questionnaire |
| PIPL audit | Personal information/forms/CRM/AI | Legal, IT | Customer drawings/trade secrets |
| Cybersecurity Law | Website/log/AI network duties | IT, website vendor | Customer data-exchange management |
This page map is editorial; data-security systems/classification are in Article 21 of the Data Security Law, and personal-information processing in the PIPL.
How should data be classified and graded?
At minimum: public, internal, trade secret/customer confidential (drawings, BOM, process, prices, contracts), personal information (contacts, ID numbers, payroll, CCTV) and important data (bulk data meeting regulatory/industry thresholds). The basis comes from law/industry/customer contract: a customer may label drawings "Confidential/Restricted" and require encryption/watermark/no subcontracting; personal information follows PIPL; important data follows the Data Security Law and industry catalogues. Classification is not an IT-only decision; confirm with customer/legal/business and implement it in labels, permissions, transmission and deletion rules.
After classification, "same level, same rules": the same level must have the same access/encryption/logging/deletion requirements whether it sits on a file server, cloud drive, email or supplier portal—not "encrypted in OA, sent freely via chat". Customer data and our data should be separated; customer A's data must not be visible to customer B/suppliers. The page can say "classified per customer contract/law", but must not publish customer names or the detailed data-classification table.
| Type | Examples | Protection | Common gap |
|---|---|---|---|
| Public | Website/brochures | Release review | Internal file leaked |
| Internal | Policies/meetings/general business | Employee access | All-staff access |
| Trade secret/customer confidential | Drawings/BOM/process/prices/contracts | NDA/encryption/watermark/least privilege | Chat apps/cloud drive |
| Personal information | Contacts/ID/payroll/CCTV | PIPL/notice/consent/minimisation | No notice |
| Important data | Data meeting regulatory/industry thresholds | Catalogue/assessment/cross-border limits | Not identified |
This classification is editorial; specifics follow the Data Security Law, industry catalogues, customer contract and company policy.
How should access control, accounts and permissions be accepted?
Least privilege plus role-based authorisation: give only the data the role needs, deny by default; isolate customer data by project/customer, and let suppliers see only their own scope; privileged accounts (admin/shared) need separate control, MFA, approval and logging; joiner/mover/leaver processes must grant/change/revoke access promptly, disabling leavers on the last day; review permissions periodically and remove unused accounts/shared links. Shared accounts, weak passwords, no MFA and ex-employees with access are the most common customer-audit findings.
Access logs must answer "who, when, from where, accessed/downloaded what", retained per contract/law; downloads/external sharing need approval/watermark/DLP. Remote/subcontractor/customer access should use controlled channels (VPN/zero trust/customer portal), not accounts sent to individuals. The page can say "least privilege/MFA/logging/periodic review", but must not publish accounts, IPs or system topology.
| Item | What to do | Evidence | Common gap |
|---|---|---|---|
| Least privilege | Role/project-based | Permission matrix | All-staff read |
| Customer isolation | Separate A/B data | Directory/permissions | Mixed storage |
| Privileged accounts | Approval/MFA/logging | Account records | Shared admin |
| Joiner/mover/leaver | Prompt grant/change/revoke | Process record | Leaver still has access |
| Review | Periodic clean-up | Review record | Never reviewed |
| Logs | Who/when/where/what | Logs | No logs |
Access-control requirements are editorial; specifics follow the customer contract, security questionnaire and company infosec policy.
How should transmission, storage, encryption and backup be described?
Transmit through controlled encrypted channels: customer portal/SFTP/encrypted email/enterprise cloud drive, not personal chat apps/QQ/public cloud drives; external files should be watermarked/password-protected/expiring with download logs; storage should be encrypted (disk/database/file), backups encrypted and access-controlled; removable media/USB controlled; printing/screenshot/photograph risks need policy/training. Where the customer requires "no local storage/only customer system", follow the contract.
"Encryption" is not a slogan: state the algorithm/key management/who holds keys/recovery; backups must be restore-tested, not just taken; logs/audit must be tamper-resistant; destruction must cover backups/caches/shared links. The page can say "encrypted transmission/storage/backup", but not "absolutely secure/impossible to leak".
| Stage | What to do | Evidence | Common gap |
|---|---|---|---|
| Transmission | Encrypted channel/portal/SFTP | Config/logs | Chat apps/cloud drive |
| External sharing | Watermark/password/expiry | Sharing record | Bare file |
| Storage | Encryption/permissions/isolation | Config | Shared drive |
| Backup | Encryption/isolation/restore drill | Drill record | Backup untested |
| Media | USB/mobile device control | Register | Free copying |
| Destruction | Backups/cache/links | Destruction record | Local only |
Transmission/storage requirements are editorial; specific encryption standards, key management and customer requirements follow the contract/policy.
| Channel | Use | Control | Common risk |
|---|---|---|---|
| Customer portal | Drawings/orders/reports | Account/permission/log/watermark | Account sharing |
| SFTP/API | Bulk/system integration | Key/allowlist/encryption | Key leakage |
| Encrypted email | Small/temporary files | Password/expiry/permission | Password sent together |
| Enterprise cloud | Collaboration/large files | Tenant/permission/watermark/log | Public link |
| Removable media | Special/offline | Register/encrypt/approve | Loss/copy |
| Personal chat/cloud | Not recommended | Prohibit/alternative | No audit/deletion |
Channel choice is editorial; specifics follow the customer contract/security questionnaire and company policy, and customer-prohibited channels must not be used.
How should subcontractors, cloud and AI tools be controlled?
Subcontractors/cloud/AI are all "data recipients": sign an NDA/data-processing agreement covering purpose/scope/security obligations/further subcontracting/incident notification/return-deletion, and supervise; further subcontracting needs approval; cloud requires region/tenant isolation/encryption/backup/exit; AI tools must not upload customer drawings/personal information/important data to public models unless customer/legal approves and enterprise/desensitised/no-training conditions are in place. Where the customer requires "no subcontracting/no cross-border/no AI", follow the contract.
The Network Data Security Management Regulation requires a contract with the recipient when providing/entrusting personal information and important data, covering purpose/method/scope/security obligations, supervision, and records kept for at least three years. Subcontracting/cloud/AI is not "sign an NDA and done": list sub-processors, data location, access method, incident notification and exit. The page can say "subcontractors/cloud/AI included in management", but must not publish supplier lists/system details.
| Object | What to do | Evidence | Common gap |
|---|---|---|---|
| Subcontractor | NDA/agreement/further-subcontract approval | Contract/approval | Private transfer |
| Cloud | Region/isolation/encryption/exit | Agreement/config | Location unknown |
| AI tools | No public models/desensitise/enterprise | Approval/config | Upload drawings |
| Supervision | Audit/questionnaire/logs | Records | No supervision |
| Records | Entrusted processing records ≥3 years | Records | No records |
| Exit | Return/delete/migration | Confirmation | Data residue |
Third-party management is editorial; contract/record requirements are in Article 12 of the Network Data Security Management Regulation.
How should security incidents/breaches be detected, notified and handled?
The plan should cover: detect (monitoring/employee report/customer notice), contain (isolate/disable accounts/segment), assess (which data/customers/individuals/important data), notify (customer per contract, individuals/authorities per law), recover (fix/verify), review (root cause/improvement). Preserve evidence (logs/timeline/scope); do not delete logs or hide the incident; notification must be truthful and verifiable, not blame-shifting or downplaying. Under PIPL, where personal information is leaked/tampered/lost or may be, the handler must immediately remediate and notify individuals and the authorities; if the measures can effectively avoid the harm, it may omit notifying individuals, but the authority may still require notification if it considers harm possible.
Customer contracts often require notification within 24/48/72 hours and prohibit public statements without consent; follow the contract while meeting legal requirements. Notification should at least cover what happened, what data/customers may be affected, what has been done, what the customer should do and a contact. The page can say "incident plan/notify per contract", but must not publish vulnerability details/incident records/customer names.
| Stage | What to do | Evidence | Common gap |
|---|---|---|---|
| Detect | Monitoring/report/customer notice | Alert/ticket | No monitoring |
| Contain | Isolate/disable/segment | Response record | Spread continues |
| Assess | Data/customers/individuals/important data | Impact assessment | Scope unclear |
| Notify | Customer contract/individuals/authorities | Notification letter | Hidden |
| Recover | Fix/verify/monitor | Recovery record | Not verified |
| Review | Root cause/improvement/drill | Report | No improvement |
Incident handling is editorial; personal-information breach notification is in Article 57 of the PIPL, and network-data incidents in Article 11 of the Regulation.
How should data return, deletion, retention and evidence be agreed?
The contract/agreement should state: what data is returned at project end/on request, in what format and within what period; what is deleted (including backups/caches/shared links/sub-processors) and how deletion is proved; what must be retained for legal/audit/litigation (legal hold), for how long and who can access it; how evidence/audit cooperation is provided. Deletion is not "delete the desktop file": cover servers/backups/cloud/email/removable media/third parties; after return, confirm receipt/completeness.
Customers may require a deletion certificate/certificate of destruction; records of entrusted processing of personal information/important data must be kept for at least three years (regulation). During retention, protection/access limits still apply; destroy at expiry. The page can say "return/delete/retain per contract", but must not publish customer data/retention lists.
| Item | What to agree | Evidence | Common gap |
|---|---|---|---|
| Return | Scope/format/deadline | Handover | Partial only |
| Deletion | Local/backup/cloud/email/sub-processor | Deletion record | Local only |
| Proof | Deletion/destruction certificate | Certificate | No proof |
| Retention | Legal/audit/litigation | Retention list | Indefinite |
| Evidence | Logs/audit cooperation | Records | No cooperation |
| Entrusted records | ≥3 years | Records | Missing |
Return/deletion requirements are editorial; specifics follow the contract, PIPL, Data Security Law and company policy.
How should security questionnaires, certification and cross-border transfer be described?
Security questionnaires should be "answered truthfully, with evidence, version-controlled": who fills, who reviews, what is a contractual commitment, what is current state/plan; not a salesperson "answering by eye". ISO/IEC 27001 (GB/T 22080-2025) is an information-security management system certification with a scope/body/validity, not "absolute security/all customer data covered"; even with a certificate, check the scope. Cross-border transfer follows PIPL routes (security assessment/certification/standard contract, etc.) and the Data Security Law/Regulation; important data/personal information/customer contract requirements need assessment—do not assume "sending to an overseas HQ/cloud is fine".
Customer questionnaires often ask: data location, access control, encryption, incident notification, sub-processors, BCP/DR, certification, penetration testing, staff training, deletion. Answering "yes" needs evidence; "planned" needs a date; a supplier/cloud provider's certification is not our certification. The page can say "questionnaire/certification scope/DPA available", but must not publish questionnaire answers/penetration reports/vulnerabilities.
| Item | What to do | Evidence | Common gap |
|---|---|---|---|
| Questionnaire | Owner/review/evidence/version | Questionnaire record | Sales fills alone |
| Certification | Scope/body/validity | Certificate | Overstated scope |
| Sub-processors | List/notice/approval | List | Undisclosed |
| Cross-border | Route/assessment/contract | Assessment/contract | Default export |
| BCP/DR | Backup/drill/RTO/RPO | Drill record | No drill |
| Testing | Penetration/vulnerability/remediation | Report | None |
Questionnaire/certification/cross-border is editorial; certification scope follows GB/T 22080-2025, and cross-border follows PIPL/Data Security Law/Regulation.
What should the page say, and what must not be published?
A public page should include: classification principles, access/transmission/storage measures, subcontractor/cloud/AI management, incident response/notification, return/deletion/retention, security questionnaire/certification scope, cross-border principles and a security contact. Do not publish: customer names/data, system topology/IPs/accounts, vulnerabilities/penetration reports, incident details, employee personal information, encryption keys. Wording must be precise: "classified protection per contract/law, least privilege, encryption, incident plan, notify per agreement", not "absolutely secure/zero breach/all data stays in China".
The page exists to let customers trust your data management, not to publish every security measure. A customer audit wants policies/evidence/drills/remediation, not slogans; over-disclosure helps attackers. Keep versions/dates when updating; review when customer contracts/regulations change.
| Page wording | Problem | Suggested wording | Basis |
|---|---|---|---|
| "Absolutely secure/zero breach" | Cannot promise | State measures/plan/notification | Risk management |
| "ISO 27001 covers everything" | Scope/validity | State certification scope/body | Certificate |
| "No data ever leaves China" | May be untrue | State cross-border route/assessment | PIPL |
| Publishing topology | Attack surface | Do not publish | Security |
| Publishing customer names | Confidentiality | Redact/authorised | Contract |
| "Fill the questionnaire any way" | Misrepresentation | Owner/evidence/review | Contract/integrity |
These red lines are editorial; specific disclosure follows the contract/confidentiality/security policy.
Go-live acceptance checklist
Ten checks: classification, access, transmission/storage, subcontractor/cloud/AI, incidents, return/deletion, questionnaire/certification, cross-border, public boundaries, and updates/evidence. Each needs an owner, evidence and review date. The pass condition is not "the page says we value information security", but that a customer can see how data is protected, how incidents are notified and how data is deleted, and the company executes the same rules.
Before go-live, run one customer project through: receive data → classify → authorise → transmit → store → subcontract/cloud/AI → incident → return/delete → questionnaire. Any step that fails is a gap in the page or the process.
| Check | Pass condition | Evidence | If it fails |
|---|---|---|---|
| Classification | Public/internal/confidential/personal/important | Classification table | Add classification |
| Access | Least privilege/isolation/MFA/leaver | Permissions/logs | Add controls |
| Transmission/storage | Encryption/watermark/backup/media | Config/records | Add measures |
| Subcontractor/cloud/AI | Agreement/sub-processor/AI ban | Contract/approval | Add agreement |
| Incidents | Plan/containment/notification/review | Drill/records | Add plan |
| Return/deletion | Scope/backup/proof/retention | Records/certificate | Add process |
| Questionnaire/certification | Truthful/evidence/scope | Questionnaire/certificate | Add evidence |
| Cross-border | Route/assessment/contract | Assessment | Add assessment |
| Boundaries | No customer/topology/vulnerability disclosure | Page test | Remove |
| Update | Date/version/reviewer | Version record | Add update |
This checklist is editorial; specific infosec/data-compliance requirements follow the law, customer contract/questionnaire and company policy.
Who should read this, who should not, and what decisions does it support?
It suits manufacturers in Changzhou and nearby areas with customer drawing/BOM/price exchange, subcontractor/cloud/AI use and customer security questionnaires/audits—especially equipment, auto parts, electronics, metal processing and exporters; it also suits procurement/IT assessing a supplier's data protection. It does not suit businesses with no customer data exchange, public information only, or teams wanting one page to replace contracts/security assessments/certification.
Read it if you are in IT, quality, procurement, legal, sales or a website vendor; you are building an infosec/data-exchange page, filling a customer security questionnaire, handling a breach/deletion request, or assessing subcontractor/cloud/AI; or you need to answer "where is the data, who can see it, how is it transmitted, what happens on a breach, how is it deleted, are you certified." Skip it if you treat an NDA as all of security, use public cloud drives/chat apps for customer data, or want a page saying "absolutely secure/zero breach". It supports self-review of classification, access, transmission, subcontracting, incidents, deletion, questionnaires, cross-border and public boundaries.
| Role | What to look at | Decision supported | Not for |
|---|---|---|---|
| IT/security | Classification/access/transmission/incidents | Systems/permissions/plan | Making compliance conclusions for customers |
| Quality/procurement | Subcontractor/supplier data flow-down | Agreements/audit/exit | NDA only |
| Legal | Contract/cross-border/incident notice | DPA/assessment/disclosure | Replacing contracts with a page |
| Sales | Questionnaire wording/certification scope | Customer communication/bids | Exaggerating/filling by eye |
| Website vendor | Modules/boundaries/updates | Page acceptance/maintenance | Making security promises for the customer |
This role split is editorial; specific duties follow the company's infosec/data-compliance policy.
Lingyi Information is a website development and enterprise AI project provider, not a cybersecurity, data-compliance, certification or legal body. This article is not a substitute for contracts/security assessments/certification or legal advice. Changzhou projects are delivered remotely or on site as confirmed per project; Lingyi is one candidate, does not claim a local office or team, and does not promise absolute security, certification, conversion or inquiries.
FAQ
Is an ISO 27001 certificate enough?
No. It is an information-security management system certification with a scope/body/validity; the customer still needs to see whether your actual access/encryption/incident/subcontractor/deletion controls cover their data. A certificate cannot replace the contract, security questionnaire or customer audit, and cannot promise "zero breach".
Can customer data be put on public cloud drives or sent via chat apps?
Not advisable, and many customer contracts prohibit it. Use the customer portal/SFTP/encrypted email/controlled enterprise cloud, with watermark/permissions/logs/expiry; personal chat apps/QQ/public cloud drives cannot guarantee access control, logs or deletion, and a leak is hard to trace.
How fast must a breach be notified to the customer?
Check the contract first: the customer may require 24/48/72 hours or "immediately"; under the law, a personal-information breach must be remediated immediately and notified to individuals/authorities (PIPL Article 57), and network-data incidents reported under the Regulation. Follow the contract + law + regulator; do not hide it, and state impact/measures/customer actions.
How should data be returned/deleted at project end?
The contract should set the return scope/format/deadline, delete local/backup/cloud/email/shared links/sub-processor data, and provide a deletion/destruction certificate; data retained for legal/audit/litigation needs a legal hold, access limits and destruction at expiry. Deleting local files alone is not deletion.
How should cloud/subcontractor/AI tools be managed?
Sign an NDA/data-processing agreement covering purpose/scope/security/further subcontracting/incident/return-deletion and supervise; for cloud, check region/isolation/encryption/exit; for AI, prohibit uploading customer drawings/personal information/important data to public models unless customer/legal approves with enterprise/desensitised/no-training conditions. Entrusted-processing records must be kept at least three years.
Are personal information and customer drawings the same?
No. Personal information follows PIPL (notice/consent/minimisation/cross-border/breach notification); customer drawings/BOM/prices are usually trade secrets/customer confidential information under the contract/anti-unfair-competition/data-security rules. They may appear in the same project and need separate classification/authorisation/deletion.
One-sentence takeaway
A Changzhou manufacturer's information-security and customer data-exchange page should not say "we value information security/signed an NDA". It should turn classification, access, transmission/storage, subcontractor/cloud/AI, incident notification, return/deletion, security questionnaires/certification and cross-border into a verifiable checklist—so a customer can see how data is protected, what happens on a breach and how it is deleted.
Method and limitations
This is a review of public regulations and project practice, not a cybersecurity, data-compliance, certification or legal audit of any company. No undisclosed customer data, system topology, vulnerabilities or incident records were used. Classification, checklists, processes and the acceptance checklist are editorial suggestions, not compliance/certification conclusions. Specific classification, access, incident notification, cross-border and deletion requirements depend on applicable law, the customer contract/security questionnaire and company policy.
Sources and scope
Information is current to 2026-11-02. The following are public official/standard pages; their scope, version and wording control.
- Data Security Law of the PRC (in force 1 September 2021), Articles 21, 27 and 29: National People's Congress. Data classification/grading, full-process security management, risk monitoring/incident handling.
- Personal Information Protection Law of the PRC (in force 1 November 2021), Articles 51 and 57: National People's Congress. Personal-information security measures; remediation and notification for leakage/tampering/loss.
- Network Data Security Management Regulation (State Council Order No. 790, in force 1 January 2025), Articles 9-12: Ministry of Ecology and Environment (reprint of the State Council text). Security management/technical measures, incident plan/reporting, entrusted-processing contract/supervision/records for at least three years.
- GB/T 22080-2025, Cybersecurity technology—Information security management systems—Requirements (identical to ISO/IEC 27001:2022, in force 1 January 2026): National Standards Full-Text Public System. ISMS requirements; certification scope/validity follows the certificate.