SecurityScorecard portfolios need relationship-state labels

Make reason for inclusion a governed field

The direct answer is to require a relationship-state record before an organization enters reporting. Use an explicit vocabulary such as current partner, possible future partner, competitor, other monitored business, former partner, or unresolved. Retain the organization identity, state, reason for inclusion, evidence source, effective start, effective end, accountable classifier, review date, and confidence. If one organization legitimately belongs to more than one state, preserve each qualified relationship rather than forcing one ambiguous portfolio label.

Do not infer state from a portfolio name, invite, report, scorecard, finding, domain, owner field, or recent activity. A business can remain under research without becoming a supplier, and a former relationship can remain relevant without belonging in a current-vendor denominator. Unknown should remain visible until the relationship is resolved. Classification changes need the prior state, new state, effective date, evidence, reason, and authorized owner.

Declare the population behind every metric

Each count, ratio, average, trend, queue, and coverage claim should state which relationship states it includes. Define the as-of time, organization identity rule, duplicate treatment, unresolved population, exclusions, inactive records, future partners, competitors, former partners, and calculation version. A headline such as vendors monitored, critical partners reviewed, findings overdue, or assessment coverage should link to the exact contributing entries and their state at that time.

Publish mixed research views separately from active-third-party operating views. A broad ecosystem portfolio can be useful for comparison and emerging-risk research, while procurement, risk, audit, or executive reporting may require only current relationships or a specifically defined subset. Do not let one broad portfolio silently inflate the vendor count, improve an assessment-coverage percentage, depress an average score, or create remediation work for an organization with no current relationship.

Preserve transitions without rewriting the series

Relationship state changes over time. A possible future partner may be rejected, become current, or remain under research; a current partner may terminate; a competitor may later become an acquisition target or provider. Record those transitions as effective-dated events. Retain which reports, invitations, findings, cases, and decisions were associated with the organization before and after the change without backfilling today's state into yesterday's metric.

When a taxonomy changes, create a bridge between old and new states and recalculate only where the reporting policy explicitly requires it. Preserve prior published snapshots, original calculation versions, affected entries, approver, and explanation. This lets leaders distinguish a real change in the partner population from a reclassification exercise or identity correction.

Test a deliberately mixed portfolio

Create a controlled portfolio containing current partners, possible future partners, competitors, other monitored businesses, former partners, duplicate organization records, and one unresolved identity. Move several entries between states across two reporting dates. Reviewers should reproduce the active-partner count, broad research count, assessment queue, finding population, and historical trend without allowing portfolio membership itself to answer the relationship question.

SecurityScorecard's public help article supports the attributed portfolio, invite, report, scorecard, finding, collaboration, and broad risk-ecosystem guidance. It does not establish a buyer's relationship classifications, population rules, organization identities, metric accuracy, workflow status, finding validity, risk decision, or outcome. Third-party risk, procurement, security, audit, data, legal, and business owners retain those judgments.

What we will watch next

Third Party Current will watch for later primary-source evidence that changes the maintained company, capability, or standards record. The next useful evidence may include implementation documentation, release details, regulator findings, corrected methods, product packaging, customer-observable workflow, or a subsequent company statement. Until then, the dated source and its stated boundary remain attached to this analysis.