← back to blog

cloud phone audit-log review for admins 2026

cloud phone audit-log review for admins 2026

cloud phone audit-log review in 2026 is the unglamorous discipline that turns a platform from “we hope it is secure” into “we can prove it is secure”. every admin action, every device wipe, every role change, every API key creation lands in an immutable log. the question is not whether you have the data. the question is whether anyone looks at it. this guide walks you through the cloudf.one audit log: what each event type means, what to scan weekly, what to alert on in real time, and how to ship logs to your SIEM for long-term retention.

if you have not yet set up RBAC or team seats, those come first. the audit log is most useful when you have a clean role and team structure to compare entries against.

what the audit log captures

every meaningful state change on the platform. ten event categories.

• user lifecycle (invite, accept, suspend, delete)
• role and permission changes
• team membership changes
• device lifecycle (lock, unlock, reboot, wipe, archive)
• session lifecycle (start, end, abandoned, recorded)
• billing changes (plan, payment, invoice events)
• security configuration (SSO, 2FA, IP allowlist)
• API key lifecycle (create, rotate, revoke)
• integration changes (webhook URL, Slack/Discord/Telegram bot)
• admin login (with IP, user-agent, location)

[SCREENSHOT: audit log table with timestamp, actor, action, target, IP, and details columns]

each entry is immutable. even admins cannot edit or delete entries. that immutability is what makes the log credible to auditors.

the weekly 15-minute review

block 15 minutes every Monday morning. open the audit log, filter to the past 7 days, scan in this order.

1. role and permission changes

filter category:role. expected entries: planned promotions, new IdP-driven assignments. unexpected entries: someone gave themselves admin, someone created a custom role with sweeping permissions.

[SCREENSHOT: audit log filtered to role changes, 5 entries with actor, target, role-from, role-to columns]

investigate any unexpected entry. usually it is an honest mistake (admin testing). occasionally it is a real issue.

2. user lifecycle for unfamiliar users

filter category:user, action:invite. scan for invitations to email addresses outside your company domain. typical indicators of a problem: free-mail addresses (@gmail.com), addresses similar to legitimate ones (typo squatting), invitations made outside business hours.

3. device wipes

filter action:device:wipe. wipes are rare. each entry should map to a known incident, end-of-tenancy, or planned reset. unknown wipes need investigation.

4. failed login attempts

filter category:login, result:failed. occasional fails are normal (typos). bursts (10+ from one IP in 5 minutes) are credential stuffing. cloudf.one auto-blocks at 20+ but the early warning is in the log.

5. API key creation

filter category:api, action:create. each new key should map to a documented automation. unknown keys are worth tracking down. revoke any key whose owner has left.

15 minutes if your account is reasonably sized. document anything unexpected and follow up.

real-time alerts to set up

three alerts you absolutely want pushed to your ops channel (Slack, Discord, Telegram).

alert 1: admin role assigned

category:role AND new_role:admin. extremely rare in steady state. if one fires unexpectedly, treat it as an incident.

def on_audit_event(event):
    if event["category"] == "role" and event["new_role"] == "admin":
        notify_ops(f"ALERT: admin role assigned to {event['target']} by {event['actor']}")

wire via the webhook automation pattern.

alert 2: SSO or 2FA disabled

category:security AND (action:sso_disabled OR action:2fa_required_disabled). should be impossible without an extreme reason. a fired alert is a security incident.

alert 3: bulk user deletes

category:user AND action:delete AND count_in_5_min > 5. could be legitimate offboarding event, could be account takeover trying to cover tracks. either way, page someone.

shipping audit logs to your SIEM

three reasons to ship audit logs to Splunk, Datadog, Elastic, or Sumo:

• long-term retention beyond cloudf.one’s 12-month default
• correlation with other logs (network, IdP, application)
• centralized alerting and dashboards across all your platforms

three options to ship them.

option 1: webhook push (recommended)

cloudf.one fires a webhook on every audit event. point it at your SIEM’s HTTP intake endpoint.

@app.post("/audit-webhook")
def receive():
    raw = request.get_data()
    if not verify_sig(request.headers, raw):
        abort(401)
    event = request.get_json()
    splunk_hec_send(event)
    return "", 204

low latency, no polling, scales to high volumes.

option 2: scheduled API export

a cron job that pulls the past hour’s events from GET /audit?since=1h and ships them. simpler but higher latency.

option 3: S3 export

cloudf.one drops a daily JSON file to your S3 bucket. great for compliance archival, not great for real-time alerting.

most teams use option 1 for real-time and option 3 for long-term archive.

what compliance auditors actually look at

if you go through SOC 2 or ISO 27001 with cloud phones in scope, the auditor will sample three things from the audit log.

• access change history: prove that role changes are reviewed and authorized
• incident response evidence: when the last security event happened, prove the audit log captured it
• separation of duties: prove no single user has unilateral access to billing AND production AND audit settings

a clean audit log with quarterly review evidence (a Notion page where you logged “reviewed week of X, no anomalies”) satisfies all three.

[SCREENSHOT: audit log filtered to last 90 days role changes, exported as CSV]

export the relevant slice as CSV when the auditor asks. they will spot-check 10-20 entries against your IdP records.

the patterns that signal trouble

after watching audit logs for years, three patterns predict actual incidents.

• late-night role changes. a role change at 2am from an IP outside your office is rarely benign.
• same actor making unusual category changes. an admin who has only ever managed users suddenly creating webhooks or API keys is suspicious.
• silent gaps. a 4-hour stretch with zero events on an account that normally generates 50/hour means the log shipping broke or worse.

build alerts for these. cloudf.one’s UI does not flag them automatically; you have to push the data to your SIEM and write the rules.

handling a confirmed incident

if you find a real issue (compromised account, malicious insider, exfiltration attempt):

1. preserve the relevant audit log entries by exporting to S3 immediately
2. revoke the affected user’s session, role, and API keys
3. force password reset and 2FA re-enrollment
4. file an incident with your security team
5. notify cloudf.one support so they can preserve their internal logs

the cloudf.one audit log is your record. their internal infra logs are theirs. both are useful in a forensic investigation.

retention and deletion

cloudf.one retains audit logs for 12 months by default on all paid plans, longer on enterprise. for 7-year retention (SOX, HIPAA), ship to your SIEM and keep there.

deletion: even if you terminate the contract, audit logs are retained for the contractual off-boarding window (typically 30-90 days). after that, hashed entries persist for compliance evidence per the legal review checklist.

frequently asked questions

can I delete an audit log entry?

no. that is the point. immutability is what makes the log credible to auditors. if you find an entry was logged in error (e.g. internal test), annotate it via the comments field but the original entry stays.

what is the audit log retention on the free tier?

free tier retains 30 days. paid plans retain 12 months. enterprise plans negotiate longer retention or guaranteed S3 export.

how do I prove the audit log itself has not been tampered with?

cloudf.one signs each entry with a chained hash. you can verify the chain via the API’s GET /audit/verify endpoint. SOC 2 auditors typically accept this.

can I see read-only actions in the audit log?

read-only views (looking at a list of devices) are not logged by default. only state-changing actions are. you can enable verbose mode for higher-sensitivity accounts but the volume increases 10-50x.

does the audit log include actions taken via the API?

yes. every API call that changes state is logged with the API key’s owner as the actor. the entry includes the API key ID for traceability.

ready to operationalize your audit log discipline? start a cloudf.one trial, wire up the webhook to your SIEM in 30 minutes, and run the first weekly review next Monday.