이것은 고객 사례가 아니라 illustrative scenario입니다. 실제 조직, 실제 사람, claimed result를 사용하지 않습니다. 목적은 Threada의 실행 가능한 Vendor Security pack이 routine security review를 request에서 recorded decision까지 어떻게 운반하는지 보여주는 것입니다. 아래 설명된 모든 surface는 실제 product capability이고, 상황은 설명을 위해 만든 것입니다.
Security team은 한 주의 의외로 많은 시간을 대부분 routine이지만 가끔은 심각한 review에 씁니다. 새 SaaS tool은 sign-off가 필요합니다. vendor는 customer data를 처리하고 싶어 합니다. 기존 policy에 대한 exception이 요청됩니다. 대부분은 알려진 형태를 따르고, 일부는 진짜 scrutinize가 필요합니다. 어려운 부분은 대개 analysis가 아닙니다. 모든 review를 일관되게, evidence에 grounded되게, record 위에 유지하는 것입니다.
그 work가 Threada의 Vendor Security pack을 통해 어떻게 흐르는지 보겠습니다.
work의 형태
Vendor Security는 case archetype과 세 가지 defined intent를 가진 workspace pack입니다.
- Vendor review: 신규 또는 갱신 vendor를 policy에 따라 평가합니다.
- Data processing review: vendor가 특정 data를 처리해도 되는지 평가합니다.
- Security exception: 기존 control에서 벗어나려는 request를 처리합니다.
reviewer는 어떤 form을 열지 결정할 필요가 없습니다. intent를 말하면 runtime이 그것을 security queue의 structured WorkItem으로 바꿉니다.
walkthrough
request가 도착했다고 상상해 보세요. 한 team이 product usage data를 받을 새 analytics vendor를 도입하고 싶어 합니다. 이 scenario에서는 configured intake channel을 통해 들어와 WorkItem이 됩니다.
Intent. reviewer 또는 channel을 통한 requester가 필요한 outcome을 설명합니다. “이 analytics vendor를 data processing approval 대상으로 review해 달라.” runtime은 vendor, 관련 data category, initial risk flag를 추출하고 Vendor Security queue에 file합니다.
Canvas. WorkItem은 adaptive canvas 위에서 열립니다. 빈 form 대신 workspace는 이 종류의 review에 필요한 field를 조립합니다. data category, processing location, sub-processor, 관련 policy profile입니다. 정보가 빠져 있으면 undifferentiated questionnaire를 보여주지 않고 정확히 그것만 요청합니다.
Evidence. evidence drawer는 assessment가 무엇 위에 서 있는지 보관합니다. vendor가 제출한 documentation, 같은 vendor의 prior review, 적용되는 policy의 citation입니다. system이 특정 claim을 grounding할 수 없으면, 갖고 있지 않은 confidence를 주장하지 않고 fallback reason을 기록합니다. reviewer는 각 source가 얼마나 fresh한지 한눈에 볼 수 있습니다.
Controls. 여기서 review는 decision이 됩니다. 새 vendor에 대한 data processing approval은 consequential action이므로 governed controls surface를 통과합니다. 먼저 proposal, 그 다음 active policy version에 대한 explicit approval입니다. policy가 이 data category에 second approver를 요구하면 gate가 강제합니다. 아무것도 조용히 실행되지 않습니다.
Run log. 모든 단계는 run log에 쌓입니다. intake, missing-info prompt, consult된 evidence, approval과 그것을 준 사람, final recorded outcome입니다. AI participant action이 distinct actor event로 나타나므로, log는 system이 처리한 단계와 사람이 결정한 단계를 명확히 보여줍니다.
team에게 남는 것
마지막에 security team은 원래 손으로 조립해야 했을 세 가지를 갖게 됩니다.
- 일관된 review. 같은 intent는 항상 같은 workspace shape을 만들기 때문에, 바쁜 주와 조용한 주 사이에 review rigor가 흔들리지 않습니다.
- 근거 있는 decision. approval은 reviewer의 기억이 아니라 specific evidence와 named policy version에 연결됩니다.
- receipt. 전체 review가 record 위에 있습니다. auditor에게 방어 가능하고, 비슷한 case를 다음에 집는 reviewer에게 읽힙니다.
routine review는 workspace가 assembly를 하므로 빠르게 움직입니다. 심각한 review는 controls surface가 요구하기 때문에 full human scrutiny를 받습니다. routine을 자동화하고 정말 어려운 case를 사람에게 라우팅하는 이 division이 전부입니다.
왜 이것을 scenario로 publish하는가
인상적인 percentage를 붙여 customer success story처럼 꾸밀 수도 있습니다. 그렇게 하지 않겠습니다. 실제로 동의한 고객이 실제 결과를 공유하기 전까지, 여기 적는 모든 것은 illustration입니다. 우리는 없는 proof를 암시하기보다 정직하게 label하는 편을 택합니다.
진짜인 것은 pack입니다. Vendor Security는 다른 모든 Threada pack과 같은 governed runtime 위의 installable workflow이며, 위에서 설명한 intent와 five surfaces를 갖고 있습니다. walkthrough가 아니라 executable version을 보고 싶다면 pack catalog가 출발점입니다.