Compliance & Security Steps beim Intake: die unangenehmen Fragen frueh stellen
Die zwei Intake Steps, die Compliance- und Security-Anforderungen vor dem Publish erfassen, warum sie vor der Bietrunde existieren und wie sie auf Service Codes mappen.
Eine Trade-in Request, die rausgeht, ohne “we need NIST 800-88 Purge” zu sagen, bekommt Bids auf dem falschen Price Level zurück — und ein Customer, der die Gap nach Award bemerkt, hat ein Problem, das niemand will. Die zwei Intake Steps für Compliance und Security existieren, damit Requirements vor dem Öffnen der Bid Round landen, nicht danach.
Der compliance step
Step im Intake Wizard, in dem der Customer Compliance Frameworks auswählt, die die Disposal erfüllen muss: GDPR data-erasure, R2v3 Nachweiskette, ADISA conformance, NAID AAA destruction, ISO 14001 environmental, sector-specific regimes (HIPAA for healthcare, PCI-DSS for payment-handling devices). Jedes ausgewählte Framework wird eine Constraint, welche ITADs bid dürfen: Nur ITADs, deren Coverage active conformance ausweist, bekommen die Request geroutet.
Der security step
Separater Step, in dem der Customer Security Requirements auswählt: data-erasure standard (NIST 800-88 Clear / Purge / Destroy), on-site vs. facility wipe, secure transport (vetted drivers, GPS-tracked vehicles), per-drive certification, witness destruction. Wie Compliance mappt jeder Pick zu einem Service Code, den die Matching Engine nutzt, um den Bidder Pool zu filtern.
Warum zwei steps, nicht einer
Weil Compliance und Security unterschiedliche Concerns sind, auch wenn sie sich überschneiden. Eine Request kann GDPR (Compliance) verlangen, ohne On-site Destruction (Security) zu verlangen, oder umgekehrt. Die Steps zu splitten hält den Wizard scannable und die Picks atomic — und der Customer, der nur eines der beiden braucht, sieht keine Fields für das andere.
Mapped to service codes
Die Picks sind nicht free-form. Jedes Compliance Framework und jedes Security Requirement mappt 1:1 zu einem Service Code im seeded Catalog der Plattform. Das Bid Form auf ITAD-Seite surfaced dieselben Codes — “the request requires NIST 800-88 Purge, your Coverage offers it, here’s the code on your bid for transparency.” Eine Vocabulary über Request, Bid und eventual Contract.
Was passiert, wenn kein ITAD matcht
Die Plattform zeigt dem Customer Relaxation Suggestions: welche Constraints, wenn gelockert, Bids anziehen würden. “Drop on-site destruction; 4 ITADs would bid.” Oder “drop ADISA conformance; 7 ITADs would bid (still NIST 800-88 Purge).” Der Customer kann vor Publishing anpassen, statt eine Request zu publishen, die crickets bekommt.