隐私影响评估：引入 PDF 工具前要回答的八个问题 / Privacy Impact Assessment for PDF Tools: Eight Questions to Answer First

一句话结论 / Short answer

隐私影响评估（Privacy Impact Assessment，简称 PIA）回答的是一个问题：把文件交给这个工具之后，里面的个人信息会走到哪里去。对 PDF 合并工具来说，这个问题的答案通常很短，因为输入往往是合同、体检报告或报税材料，而合并这一步要么带走一份副本，要么不带。这篇把评估拆成八个能在一个下午填完的空格，给出填对了和填错了的对照，最后附一页可以直接归档的结论模板。

A privacy impact assessment answers one question before you adopt a tool: once a file is handed over, where does the personal data inside it go. For a PDF merge tool the answer tends to be short, because the input is usually a contract, a medical record or a tax return, and the processing step either takes a copy off the device or it does not. This article turns the assessment into eight questions you can fill in during one afternoon, gives a table of answers that hold up and answers that do not, and ends with a conclusion page you can file.

常见的失手方式有两种。第一种是把评估写成政策摘要，通篇是重视隐私、符合法规这类表述，没有一处能验证；第二种相反，把评估写成满分升级标，最后只有结论没有人签字，工具升级之后再没人看过第二遍。能用的评估落在两者之间：每条都能核到一个动作，整份东西一页 A4 装得下。

There are two common ways this goes wrong. One writes the assessment as a policy summary, full of statements about taking privacy seriously, with nothing in it that anybody can check. The other turns it into a procurement scorecard that ends in a conclusion nobody signed, reopened only after an incident. A usable assessment sits between them: every line maps to an action someone can run, and the whole thing fits on one page.

说明：下面是给工具选型和内部制度用的核对口径，不是法律意见。具体义务以适用的法规和本单位法务的判断为准。

评估边界划在哪里 / Where the assessment stops

边界要先划，否则八个空格会一路扩展成三十个。这里只评估「文件处理」这一件事：文件从被选中到得出结果中间经过的步骤。账号体系、支付流程、客服工单属于另一份评估，不要混进来。

Draw the boundary first, or the eight cells grow into thirty. This assessment covers file processing and nothing else: the steps between selecting a file and getting a result. Account systems, payment flows and support tickets belong to a separate document and should not be folded in here.

• 纳入范围：导入、处理、导出、事后残留四个环节上的所有写入动作
• 不纳入：官网本身的 Cookie、邮件推送、广告投放这些与文件无关的链路
• 时间边界：以工具的当前版本号为准，版本变更即触发复核，而不是等年度检查
• 责任边界：谁填谁签，第三方依赖由引入方一起担责，不由供应商代填

• In scope: every write action across ingress, processing, export and residue
• Out of scope: site cookies, newsletter delivery and advertising pixels, none of which touch the file
• Version boundary: assess the current release number, and let a version change trigger a recheck rather than waiting for the annual review
• Ownership: whoever fills it in signs it, and third-party dependencies sit with the adopting team rather than the vendor

第三条最常被漏掉。工具改一次前端打包，数据路径可能跟着改，而年度复核周期通常比版本节奏慢得多。把版本号写进表头，比写一句「本评估长期有效」有用。

Row three is the one that gets missed. A single front-end rebuild can move the data path, and annual reviews run slower than release cycles. Putting the version number in the header does more work than declaring the assessment valid indefinitely.

数据流向的四个落脚点 / Four places data lands

八个空格里有五个其实在问同一件事：文件到底停在了哪里。先把四个环节列出来，再回答具体格子，填错的次数会少很多。

Five of the eight cells ask the same thing in different words: where does the file actually come to rest. Listing the four stages first and answering the cells afterwards cuts most of the guesswork.

最后一行的差别决定了后面几格的难度。文件不出本机时，「保存多久」这一格直接写不适用；一旦有服务端，同一格就要问 CDN 缓存、访问日志、队列落盘和备份四件事，而这四处的保留策略往往不是同一个团队在管。

The last row decides how hard the remaining cells get. When nothing leaves the device, retention reads not applicable and stops there. Add a server and the same cell has to cover CDN caches, access logs, queued writes and backups, which four teams usually own separately.

服务端架构那一条分支的差别见 /blog/client-side-vs-server-side-pdf-tools，自己动手验证面板请求的做法见 /blog/devtools-network-tab-privacy-guide。

八个问题的核对表 / Eight questions, with answers

这张表就是评估本体。打印出来填完，再签上名字和日期，一份能用的隐私影响评估就成型了。第二列和第三列要一起看：出现第三列里任何一种写法，第一列那一格就算没答。

This table is the assessment. Print it, fill it in, sign it with a date, and you have something usable. Read columns two and three together: any wording from column three means the cell counts as unanswered.

第一格和第二格承担最多重量，也最常被敷衍。把个人信息四个字换成具体的字段名之后，第五格里的留存天数才有意义：一张只印着姓名的名片三十天，和一份带着诊断结论的病历三十天，不是同一件事。

Cells one and two carry most of the weight and get the least attention. Once the phrase personal data is replaced by actual field names, the retention number in cell five means something: thirty days for a business card carrying only a name is not the same as thirty days for a record carrying a diagnosis.

第六格常被当作可选项，而它决定了前面五格能不能被验证。没有自测方法时，第三格到第五格只能听供应商说，评估也就退化成对方营销文案的摘录。验证方法本身见 /blog/devtools-network-tab-privacy-guide，七条原则与这张表的对应关系见 /blog/privacy-by-design-pdf-tools。

Cell six gets treated as optional, and it is the one that decides whether cells three to five can be checked at all. With no published method, everything from cell three onwards rests on the vendor telling you, and the assessment becomes a summary of their marketing copy. The verification method itself is in /blog/devtools-network-tab-privacy-guide, and how the seven principles map onto this table is in /blog/privacy-by-design-pdf-tools.

结论怎么写才有用 / Writing a conclusion that holds up

结论页只需要四段，每段都能独立被检查。写出来之后交给法务或外部审计，对方不需要回来追问任何一句。

The conclusion page needs four paragraphs, each checkable on its own. Hand it to legal or to an external auditor and nobody should need to come back with questions.

1. 这次处理了什么：字段清单加上一份代表性文件名，不用贴文件内容
2. 依据哪一条：写明适用法规或内部制度的条款编号，以及为什么触发这次评估
3. 哪一格没答上：空缺的一格写清楚原因，是供应商没公开还是功能不存在
4. 降级动作与责任人：每一条动作配一个名字和一个日期，复核日期一并写下

1. What was processed: the field list plus one representative file name, with no need to paste contents
2. Under which provision: the clause number in the applicable regulation or internal policy, and why this assessment was triggered
3. Which cell stayed empty: name it, and say whether the vendor has not published it or the capability does not exist
4. Mitigation and owner: one name and one date per action, plus the recheck date

第三段是这份东西的价值所在。填得满满当当、看起来没有风险的评估通常说明没人认真查；承认有一格填不上来，反而证明整份表过了一遍。GDPR 那一侧的条款对照见 /blog/gdpr-compliant-pdf-tools，个保法下八个可核对的点见 /blog/china-pipl-pdf-tools-requirements，操作记录这块见 /blog/pdf-file-audit-trail-requirements。

Paragraph three is where the value sits. A fully answered assessment showing no risk at all usually means nobody looked hard, while admitting one open cell is evidence that the table was worked through. The clause-by-clause view for GDPR is in /blog/gdpr-compliant-pdf-tools, the eight checkable points under the PIPL are in /blog/china-pipl-pdf-tools-requirements, and the operational record side is in /blog/pdf-file-audit-trail-requirements.

合并这一步在 pdfmergenext.shop 全程在本机完成，第三格到第五格基本可以一句带过：没有接收方，因此没有留存期限、没有跨境路径、也没有备份口径要谈。想把这一句写进内部制度时，配上下游疏散的例子会更好用，零上传的实现方式见 /blog/how-zero-upload-pdf-tools-work。

Merging on pdfmergenext.shop runs entirely on your device, so cells three to five mostly close in one line: there is no receiving party, and therefore no retention window, no transfer path and no backup policy to negotiate. Writing that into an internal policy works better with an example of what the other route looks like, and how zero-upload is implemented is in /blog/how-zero-upload-pdf-tools-work.

七条原则的逐条口径见 隐私设计：七条原则怎么逐条核对，数据出境那一格怎么填见 PDF 工具的数据出境影响，全部文章在 /blog。