Direct answer: A technical-data / drawing-request page cannot be just a "download center" or "contact us for drawings." It should state the data tiers (public, registered, NDA, on-site only), the request and approval process, the scope of the confidentiality agreement, watermarking and traceability, revision and change control, access and download logs, formats and units, and withdrawal and destruction. Otherwise, customers cannot get the right drawing at the RFQ stage, sales sends the full BOM, the revision does not match the quotation, and no one can later say who leaked what.
This guide is for sales, engineering, R&D, legal, IT, quality, and website teams at manufacturers in Changzhou and nearby industrial areas. It explains how to build and accept a technical-data / drawing-request page. Information is current to 2026-11-01. It is a review of public rules, standards, and project practice, not legal, IP, data-security, or certification advice; specific tiers, NDA terms, permissions, and retention depend on the contract, company policy, applicable law, and professional advice.
A drawing is not "sent and done"; it is who receives it, which revision, for what purpose, whether it may be forwarded, and when it is withdrawn. A watermark is a tracing measure, not a confidentiality agreement. An NDA does not mean you may send every document in one package.
How does the technical-data page relate to RFQ, sample, and customer-portal pages?
The RFQ page answers how quotes and lead times work; the sample page answers how first articles are approved; the customer portal answers orders, reconciliation, and progress; the technical-data page answers which drawings are needed for quoting and manufacturing, in what format, which revision, who may receive them, and how they are authorised. They must align: the revision cited at RFQ must be the same one used for quotation, first article, and mass production.
The most common break is: sales sends a PDF drawing over a chat app, the customer forwards it to three suppliers for comparison; the quotation does not state the drawing number and revision, and by mass production the drawing has changed; the customer asks for a STEP model, and engineering sends the full assembly including undisclosed internal structure. Stating data tiers and the request process on the website lets sales stop improvising and tells the customer which route to take.
| Page/entry | Answers | Audience | Cannot replace |
|---|---|---|---|
| RFQ page | What is needed to quote, lead time, trade terms | Procurement, project | Drawing authorisation and revision control |
| Sample/FAI page | FAI, dimensional report, sample approval | Quality, engineering | Confidentiality and permissions |
| Customer portal | Orders, reconciliation, progress, shipment | Existing customers | Pre-sales drawing requests and NDA |
| Technical-data page | Tiers, requests, NDA, revisions, logs | Customer engineering, procurement, legal | The contract and technical agreement itself |
This page map is editorial; confidentiality during contracting is in Article 501 of the Civil Code, and the trade-secret definition in Article 9 of the Anti-Unfair Competition Law.
What are the data tiers, and what goes in each?
Use at least four tiers: public (brochures, outline drawings, general specifications), registered (ordinary documents after company-email verification), NDA (detailed drawings, BOM, inspection specifications, process parameters), and on-site only (core formulas, source code, undisclosed designs, critical process windows). The higher the tier, the stricter the approval, the narrower the permission, and the more detailed the log. Do not put "public brochure" and "full production drawing set" behind the same download button.
Tiering is based not on file size but on the competitive impact of disclosure and whether the customer actually needs it. An RFQ usually needs the outline, mounting interface, key dimensions, material grade, surface treatment, and acceptance criteria; the full BOM, internal structure, tooling drawings, and program parameters are often needed only after nomination. Separating "needed to quote" from "needed after nomination" helps the customer and reduces unnecessary spread.
| Tier | Typical documents | Access | Control |
|---|---|---|---|
| Public | Brochures, outline drawings, general specs, interface dimensions, certificate list | Direct download | No customer-specific data; version visible |
| Registered | Detailed specs, material notes, packaging drawings, standard inspection items | Company-email registration/form | Company verification, purpose, basic log |
| NDA | Detailed drawings, BOM, inspection specs, process parameters, tooling concepts | NDA + manual approval + expiring link | Project-based authorisation, watermark, logs, expiry |
| On-site | Core formulas, source code, undisclosed designs, critical process windows | On-site review/controlled terminal | No download; register, escort, no photography |
These tiers are editorial; a trade secret requires that the information is not public, has commercial value, and is subject to corresponding confidentiality measures, per Article 9 of the Anti-Unfair Competition Law. Specific tiers follow company policy and customer contracts.
What does a customer actually need at the RFQ stage?
Match the document to the purpose: comparison needs the outline, key dimensions, material, surface treatment, tolerances, and acceptance criteria; structural design needs 3D models and mounting interfaces; production introduction needs full 2D drawings, BOM, inspection specifications, packaging, and tooling information. For each, state the format, the depth, and whether an NDA is required—do not let "we need drawings" cover everything.
Many RFQs stall not on price but on mismatched documents: the customer sends a screenshot with no drawing number or revision; the supplier needs STEP to evaluate tooling; the customer's internal BOM and drawing revisions disagree. The website can offer a "document needs" list by purpose, so the customer ticks what applies and sales approves by tier instead of guessing.
| Purpose | Usually needed | Format/depth | Common gap |
|---|---|---|---|
| Initial comparison | Outline, key dimensions, material, finish, quantity | PDF/DWG outline with units | Screenshot without drawing/revision |
| Structural review | 3D model, mounting interface, tolerance chain | STEP/IGES with simplified internals | Full assembly sent |
| Tooling quote | Draft, parting line, gate, critical fits | STEP + 2D critical dimensions | Appearance drawing only |
| Production introduction | Full 2D drawings, BOM, inspection specs, packaging | Controlled PDF + controlled BOM | Revision differs from quote |
| Change review | ECN/PCN, before/after drawings, impact | Change pack + comparison | New drawing without change marks |
These needs are editorial; the depth delivered follows the project, contract, and technical agreement, with no promise that every document will be provided.
How should the NDA and approval process be made enforceable?
An NDA should state the parties, scope of confidential information, purpose, exceptions, term, recipients/affiliates/subcontractors, return or destruction, breach, and dispute resolution. The request process should state who approves, for how long, which files, whether it is project-limited, and whether access expires automatically. Do not replace an enforceable confidentiality arrangement with "submitting means you agree."
Article 501 of the Civil Code provides that a party who learns trade secrets or other information that should be kept confidential during contract negotiations must not disclose or improperly use it, whether or not the contract is concluded, and is liable for losses caused by disclosure or improper use. In other words, drawings a customer sends during an RFQ remain protected even if no deal is reached. Conversely, documents you send to a customer should have a defined recipient and scope of use—do not assume "sent" means "free to use."
| Term/step | What to state | Evidence | Common gap |
|---|---|---|---|
| Parties | Full legal names, affiliates and subcontractors | Business licence/signature page | Personal chat account only |
| Scope | Which files, oral information, samples, models are confidential | Attachment list | Too broad or too narrow |
| Purpose | Quotation/evaluation/manufacturing only; no reverse engineering or other use | Purpose statement | Purpose not limited |
| Exceptions | Public, independently developed, lawfully obtained from a third party | Clause | No exceptions |
| Term | Effective date, confidentiality period, obligations after the project | Signed date | Perpetual term unenforceable |
| Return/destruction | Return or destroy on request/completion, with confirmation | Confirmation letter | Only "do not share" |
| Breach | Liability, damages, dispute resolution | Contract clause | No remedy |
These NDA points are editorial and not a contract template or legal advice; legal counsel should review before signing. The pre-contract confidentiality duty is in Article 501 of the Civil Code.
Watermarks, traceability, and whether a file can be "taken back"
A watermark should carry the receiving company, recipient name, date, document number/revision, and "for evaluation of project X only." PDFs can carry visible watermarks and document properties; 3D/2D files can carry identifiers in the title block, layers, or exported file. Watermarks support tracing and deterrence; they do not prevent screenshots, photography, or forwarding, and they do not replace an NDA, permissions, or logs.
The common failures are a watermark with only a company name and no person, so a leak cannot be traced, or a watermark placed in blank space that disappears when the image is cropped. Use a semi-transparent watermark across pages and key views, and write the recipient and authorisation number into file properties. Send an expiring link instead of an attachment where possible; a link can have a validity period, download limit, and revocation, so it can be withdrawn at project end or when staff change.
| Measure | How | What it proves | Cannot replace |
|---|---|---|---|
| Visible watermark | Company, name, date, project, document/revision | Source and purpose | NDA and permissions |
| Document properties | Author, recipient, authorisation number, export time | File identity | Tamper resistance |
| Expiring link | Validity, download limit, revocation, email binding | Access control | Spread after download |
| Download log | Who, when, which file/revision, IP/account | Access trail | Offline photography |
| Return confirmation | Return/destroy at project end | Performance of obligation | Actual deletion |
These technical measures are editorial; taking "corresponding confidentiality measures" is one element of a trade secret under Article 9 of the Anti-Unfair Competition Law, and specific measures follow company security policy.
How should drawing revisions and changes be controlled?
Give every drawing a unique number, revision, effective date, and change record; quotation, first article, mass production, and after-sales must cite the same revision; after an ECN/PCN, mark the old revision obsolete and remove it from the download area—do not just overwrite the file name. A customer quoting from an old revision while the supplier builds to a new one is the most common source of quality and commercial disputes.
Revision control is not only engineering's job. The quotation should state "based on drawing number/revision"; the contract/technical agreement should attach a controlled drawing list; the FAI report should state the inspection revision; the customer portal/download page should show the "current revision" and mark historical revisions as not usable for new orders. If the customer insists on the old revision, record a written deviation/change instead of a verbal agreement.
| Step | What to state | Evidence | Common gap |
|---|---|---|---|
| Number/revision | Unique number, revision, effective date, page | Title block/version page | File name used as revision |
| Change record | What changed, why, affected dimensions/materials | ECN/PCN | New drawing only |
| Quote reference | Drawing number/revision and receipt date | Quote attachment | Product name only |
| FAI/production | Inspection revision, deviation approval | FAI/deviation form | Revision mismatch |
| Obsolete/withdraw | Mark obsolete, remove from downloads, notify customers | Withdrawal record | Old revision still downloadable |
| Archive | Keep old revisions for traceability only; not for new orders | Archive record | Old and new mixed |
Revision control is editorial; the specific change process follows the quality system and customer contract; see the PCN/EOL page for product change notification.
How should permissions, accounts, and download logs be accepted?
Accounts should be tied to a named person and company email, authorised by project, and given an expiry date; access must be revocable immediately on departure, role change, or project end. Download logs should record at least the account, company, time, file/revision, action, and source IP. More logs is not the goal; the goal is answering "who took which revision, when, and under what authorisation."
Article 27 of the Data Security Law requires organisations carrying out data processing to establish a full-process data security management system, provide data-security training, and take technical and other necessary measures to protect data; those processing data via the internet must do so on the basis of the cybersecurity classified-protection system. A drawing download page is part of data processing, so at minimum it needs accounts, permissions, logs, and incident handling—do not treat "a link to a cloud drive" as a complete solution.
| Control | Requirement | Evidence | Common gap |
|---|---|---|---|
| Identity/company verification | Name, company, company email, purpose | Registration record | Personal email can download |
| Least privilege | Per-project/file authorisation, not all-open | Permission matrix | One account sees everything |
| Expiry | Links/accounts expire automatically | System setting | Permanent link |
| Revocation | Immediate on departure/role change/project end | Revocation record | Still active after departure |
| Logs | Account, time, file/revision, action, IP | Log export | Visit count only |
| Incident handling | Freeze, notify, review for leaks/anomalies | Incident record | No plan |
Security duties are in Articles 27 and 29 of the Data Security Law; log fields and retention follow company policy, contracts, and legal advice—this article does not set a single retention period.
How should formats, units, and the files themselves be accepted?
Use PDF for reading and controlled issue, STEP/IGES for 3D evaluation, and DWG/DXF for 2D editing; state the units (mm), coordinate system, layers, title block, revision, and whether internal structure is included. Check that external files open, fonts are not lost, external references are packaged, and internal comments, hidden layers, or other customers' information are not included.
The page does not need to teach CAD, but it should tell customers which formats and revisions are provided and what is simplified. For example, a STEP model sent to a customer can remove internal oil passages, wiring routes, and proprietary structure; a PDF can be flattened and stripped of editable fields. Format is not a security measure, but it reduces the chance of sending the wrong file.
| File | Purpose/requirement | Checks | Common gap |
|---|---|---|---|
| Reading, controlled issue, approval | Number/revision, fonts, pages, watermark | Screenshot/scan | |
| STEP/IGES | 3D structural review, tooling quote | Units, coordinate system, solid integrity | Surfaces/broken solids |
| DWG/DXF | 2D dimensions, tooling/gauge design | Layers, external references, revision | Missing fonts/references |
| BOM | Cost, procurement, alternative materials | Levels, revision, alternatives, controlled status | Other customers' data included |
| Inspection spec | FAI, production acceptance | Sampling, gauges, criteria, revision | Inconsistent with drawing |
Formats and checks are editorial; the actual delivery format, simplification, and controlled status follow the project, contract, and technical agreement.
What should the page say, and how should it link?
Include data tiers, a document list by purpose, the request process and approval time, the NDA explanation, watermarking and traceability, revisions and changes, permissions and logs, formats and units, and a contact; link to the RFQ page, sample/FAI page, customer portal, and quality/change-notification pages. The public page states what can be provided and how to request it, not customer-specific drawings or internal approval details.
Make it a "technical-data request" page rather than a "download center": first let the customer choose the purpose (comparison/structural review/tooling quote/production introduction/change), then show the corresponding tier and request route; NDA-tier documents go through manual approval and an expiring link; the page ends with a technical-data contact, not just a sales switchboard. The customer then knows the next step, and sales does not have to explain it every time.
| Module | What to write | Evidence/asset | Common gap |
|---|---|---|---|
| Data tiers | Public/registered/NDA/on-site and contents | Tier table | Only a "download center" |
| List by purpose | Comparison, structure, tooling, production, change | Checklist | Customer has to guess |
| Request/approval | Form, company verification, approver, time, notification | Flow diagram | Email address only |
| NDA | Signing method, scope, term, return/destruction | Template/record | Verbal promise |
| Watermark/logs | Watermark fields, expiring link, logs, revocation | System screenshot/sample | No traceability |
| Revision/change | Number/revision, ECN/PCN, obsolete withdrawal | Version page/change pack | Mixed revisions |
| Links/contact | RFQ, sample, portal, change notice; technical contact | Page test | Broken links/sales only |
These modules are editorial; public scope, approval rights, and NDA templates follow company policy, contracts, and legal advice.
Go-live acceptance checklist
Ten checks: data tiers, list by purpose, request and approval, NDA, watermark and traceability, revision and change, permissions and logs, formats and units, withdrawal and destruction, and links/contact. Each needs an owner, evidence, and review date. The pass condition is not "the page has a download button"; it is that the customer knows what to request, how it is approved, and how far it may be used.
Sales, engineering, R&D, legal, IT, quality, and the website vendor can share this list. Before go-live, run one real RFQ through the flow: customer selects purpose → submits company details → approval → signs NDA → receives a watermarked expiring link → download log is visible → access is revoked at project end. Any step that fails is a step the page has not yet passed.
| Check | Pass condition | Evidence | If it fails |
|---|---|---|---|
| Data tiers | Four tiers clear; public and controlled separated | Tier table | Re-tier |
| List by purpose | Comparison/structure/tooling/production/change lists | Page checklist | Add lists |
| Request/approval | Form, verification, approver, time executable | Process record | Add process |
| NDA | Parties, scope, purpose, term, return/destruction | Template/signed record | Legal revision |
| Watermark/trace | Company, name, date, document/revision, project | Sample file | Add fields |
| Revision/change | Number/revision, ECN/PCN, obsolete withdrawal | Version record | Add change pack |
| Permissions/logs | Named, least privilege, expiry, revocation, exportable logs | Config/logs | Tighten access |
| Format/units | PDF/STEP/DWG open; units/layers/title block consistent | Sampled files | Re-export |
| Withdrawal/destruction | Expiry, project-end return, destruction confirmation | Revocation/confirmation | Add mechanism |
| Links/contact | RFQ/sample/portal/change reachable; technical owner named | Page test | Fix links |
This checklist is editorial; specific documents, approvals, NDA, logs, and retention follow the law, contracts, company policy, and professional advice.
Who should read this, who should not, and what decisions does it support?
It suits manufacturers in Changzhou and nearby areas that exchange drawings, models, BOMs, and inspection specifications during RFQ, sampling, or production—especially those supplying brand customers, export customers, or custom-equipment projects. It does not suit standard-parts sellers whose public catalogue is enough to quote and who never receive customer drawings.
Read it if you are in sales, engineering, R&D, legal, IT, quality, or a website vendor; you are building a technical-data download page, drawing-request process, NDA template, customer-portal permissions, or revision control; or you need to decide which documents are public, which need an NDA, what the watermark says, what the logs keep, and how old revisions are withdrawn. Skip it if you put customer drawings in a public download area; you use "submitting means you agree" instead of an enforceable confidentiality arrangement; or you want one page to replace legal, IP, data-security, or certification advice. It supports self-review of data tiers, request and approval, NDA scope, watermark traceability, revision changes, permission logs, and page acceptance.
Lingyi Information is a website development and enterprise AI project provider, not a law firm, IP agency, data-security certification body, or CAD vendor. This article is not a substitute for legal, IP, data-security, or certification 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 that data will never leak, that a customer will close, or that inquiries will follow.
FAQ
Can drawings go straight into a public download area?
Only public-tier documents are suitable for direct download, such as brochures, outline drawings, general specifications, and already-public certificate lists. Detailed drawings, BOMs, inspection specifications, and process parameters should be managed at registered/NDA/on-site tiers. Putting production drawings in a public download area undermines the basis for "taking corresponding confidentiality measures."
Can a watermark replace an NDA?
No. A watermark identifies source, purpose, and traceability; it does not prevent screenshots, photography, or forwarding, and it does not create rights and obligations between the parties. An NDA addresses whether and how the information may be used and what happens on breach; watermarks and logs address whether a leak can be traced. Use both.
A customer asks for a STEP model and the full BOM—should we send them?
It depends on purpose and tier. Structural evaluation usually gets a simplified STEP with proprietary internals removed; the full BOM is generally provided only after nomination/production introduction, under an NDA and project authorisation. Do not send the full BOM to multiple bidders at the RFQ stage, and do not use "the customer asked" as a reason to skip approval.
Once an NDA is signed, can we send everything?
No. An NDA covers only the agreed scope and purpose; it is not unlimited authorisation. Apply least privilege: send only the drawings the project needs, provide a simplified version where possible, and use an expiring link rather than a permanent attachment.
What if the drawing revision and the quotation do not match?
Use the drawing number/revision cited in the quotation as the baseline, check the ECN/PCN and the before/after differences immediately, and if the customer insists on the old revision, record a written deviation/change and reconfirm price, lead time, and inspection criteria. Do not replace a specific revision with "latest version."
How long should download logs be kept?
The law does not set a single period; companies should decide by contract, project duration, limitation-period considerations, and internal policy, and write it into the data-security/records policy. At minimum, cover the project performance period and likely dispute period; logs should be exportable and tamper-resistant, and handled per agreement at project end or on customer request.
One-sentence takeaway
A Changzhou manufacturer's technical-data / drawing-request page should not be a "download center." It should turn data tiers, purpose-based requests, NDA scope, watermark traceability, revision changes, permission logs, formats and units, and withdrawal/destruction into an executable checklist—so the customer knows what to request, how approval works, and how far the data may be used.
Method and limitations
This is a review of public rules, standards, and project practice, not a compliance certification or legal opinion on any company, drawing, NDA, data system, or IP matter. No undisclosed customer drawings, BOMs, processes, or download logs were used. Data tiers, approval flows, watermark fields, log fields, and the acceptance checklist are editorial suggestions, not legal, IP, data-security, or certification conclusions. Specific tiers, NDA terms, permissions, log retention, and disclosure requirements depend on the law, contracts, company policy, and professional advice.
Sources and scope
Information is current to 2026-11-01. The following are public official/primary pages; their scope, version, and wording control.
- Anti-Unfair Competition Law of the PRC (2019 amendment): National People's Congress. Article 9 (definition of trade secrets and infringement), Articles 21 and 32 (liability and burden of proof).
- Civil Code of the PRC, Article 501: Cyberspace Administration of China. Trade secrets or other confidential information learned during contracting may not be disclosed or improperly used.
- GB/T 29490-2023, Enterprise intellectual property compliance management system—Requirements (published 2023-08-06, effective 2024-01-01, fully replacing GB/T 29490-2013): National Standards Full-Text Public System. Trade-secret compliance and typical prohibited conduct are addressed in Annex B.
- Data Security Law of the PRC, Articles 27 and 29: National People's Congress. Full-process data-security management, internet data-processing duties, and incident handling.
- Interpretation of GB/T 29490-2023: China National Intellectual Property Administration. Revision background, compliance elements, and Annex B; certification transition per the 2023 No. 27 announcement of the CNCA and CNIPA.