Swif.ai's Shadow IT Risk Score evaluates the security risk of each (employee, app) pair daily. The scoring model combines multiple dimensions — access frequency, privilege level, data sensitivity, anomalous behavior, and compliance — into a single bounded score from 0 to 100, giving security teams a clear, comparable risk view across the entire organization.
How the Daily Risk Score Works
Each day, Swif.ai calculates a risk score for every unique employee + application combination. The scoring pipeline has two stages:
Activity gate — If a user had no access events for an app on a given day, the risk score is automatically 0. This eliminates false "ghost risk" from inactive accounts.
Weighted score — If there is activity, the system evaluates five risk dimensions and combines them using weighted percentages.
Total Risk Score Formula
Daily Score = Activity Gate × (35% Frequency + 15% Privilege + 20% Sensitivity + 20% Anomaly + 10% Compliance)
The final daily score is stored as a whole number between 0 and 100.
Scoring Dimensions
1. Access Frequency Score (35% weight)
Purpose: Measures how heavily a user is accessing an app relative to what's normal.
Unlike a simple event count, the frequency score uses a bounded saturation curve — it rises quickly at first but flattens out as usage grows, preventing extremely high-traffic apps from dominating the risk score.
The system compares a user's daily access count against the 95th percentile of that app's usage across the organization over the past 28 days. This means the score reflects whether a user's behavior is unusual for that specific app, not just whether they accessed it a lot.
Access Pattern | Approximate Score Range |
Minimal use (a few events) | 0–20 |
Typical use | 20–50 |
Heavy use (well above org norm) | 50–80 |
Extreme use | 80–100 (asymptotic) |
2. Privilege Level Score (15% weight)
Purpose: Reflects the risk associated with the user's role within the app.
Privilege Level | Score |
Admin | 100 |
Standard | 40 |
Unknown | 20 |
Higher privilege levels carry more risk because admin-level access can cause greater damage if compromised.
3. Data Sensitivity Score (20% weight)
Purpose: Evaluates the sensitivity of the data the application handles.
Sensitivity Level | Score |
Highly Sensitive | 100 |
PII (Personally Identifiable Information) | 80 |
Business Sensitive | 60 |
Internal | 40 |
Unknown | 50 |
Public | 20 |
4. Anomaly Score (20% weight)
Purpose: Flags unusual access patterns that may indicate compromised credentials, unauthorized access, or policy violations.
Anomalies are calculated as rates (proportion of anomalous events out of total events), not raw counts. This means a single suspicious event among few total events weighs more heavily than the same event buried in thousands of normal ones.
Anomaly Type | Max Contribution | How It's Detected |
Night Access | 35 points | Access events occurring before 5:00 AM or after 11:00 PM local time |
IP Address Change | 25 points | Consecutive events from different IP addresses for the same user + app |
Geo Distance > 500 km | 25 points | Access from locations more than 500 km apart for the same user + app |
Cross-Country Access | 15 points | Access from a different country than previously observed |
Note: Since IP address is a required field, Cross-Country Access will always appear alongside IP Address Change when a country change is detected.
The total anomaly score is clamped to a maximum of 100.
5. Compliance Score (10% weight)
Purpose: Reflects the compliance posture of the application.
Compliance Status | Score |
Non-Compliant | 100 |
Partially Compliant | 50 |
Fully Compliant | 0 |
Weekly and App-Level Aggregation
User-App Weekly Score
The weekly score is a time-weighted average of the past 7 days of daily scores. More recent days carry slightly more weight than older days, so the score reflects current behavior while still smoothing out one-off spikes.
Days with no activity contribute a score of 0.
App-Level Score
The app-level risk score is calculated by combining:
70% from the median weekly score across all users of that app
30% from the 90th percentile weekly score across all users
This robust aggregation prevents a single outlier user from disproportionately inflating an app's overall risk rating.
Risk Level Mapping
Total Score | Risk Level |
0–35 | 🟢 Low |
36–55 | 🟡 Medium |
56–75 | 🟠 High |
76–100 | 🔴 Critical |
System Service Exclusion
Automated system services (such as provisioning services, background sync agents, and service accounts) are classified separately from user-interactive applications. System-level services do not appear in user-facing risk scores or app risk rankings, since their high-volume, machine-driven traffic does not represent human security risk.
Example Risk Score Breakdown
Consider an employee accessing a Productivity app with the following characteristics:
Access frequency: 3 events in the day
Privilege: Unknown (score: 20)
Data sensitivity: PII (score: 80)
Anomalies: IP Changed + Cross-Country Access (anomaly score: 40)
Compliance: Fully Compliant (score: 0)
The system would compute:
Frequency score based on how 3 events compares to org norms for this app
Final score ≈ Activity Gate × (35% × Frequency + 15% × 20 + 20% × 80 + 20% × 40 + 10% × 0)
The result is a single integer score in the 0–100 range that security teams can use to prioritize investigation.
Key Design Principles
Bounded scoring: Every daily score falls within 0–100, making scores comparable across users and apps.
Rate-based anomaly detection: Anomaly severity is measured by the proportion of unusual events, not just the count — a few anomalous events in light usage is more concerning than the same number in heavy usage.
Noise-resistant aggregation: App-level scores use median + 90th percentile blending so that one high-risk user doesn't skew the entire app's rating.
Zero activity = zero risk: No access on a given day means no risk score for that day.