iThemes Security Pro spreads its operational data across a handful of tables: wp_itsec_logs for every recorded event, wp_itsec_lockouts for active host and user blocks, wp_itsec_temp for in-flight tracking, and wp_itsec_user_groups for role-based rules. The default Security menu shows each in its own screen with its own filter set, so a single suspicious IP can mean opening three tabs to see the full picture.

SleekView reads each table as a grid and lets you pivot between them with a saved-view click. Logs gain proper columns for module, code, severity, and remote IP. Lockouts expose lockout_type, lockout_host, lockout_user, and the expiry, so unbans become a one-click cell edit. User group rules show their members and the modules they apply to, instead of buried inside a settings card.

Edits route through the same iThemes APIs the default UI uses, so unblocking a host or extending a lockout honours the plugin's own hooks. The result is the workflow security-conscious site owners already piece together by hand: see who got banned, why, by which module, and decide what to do without losing context.

Security questions almost always cross tables. A lockout in wp_itsec_lockouts is only useful if you can see the matching log row in wp_itsec_logs that triggered it, and the user group rule in wp_itsec_user_groups that put the affected account in scope. iThemes Security Pro records everything you need but spreads it across screens, so the answer to "why is this customer locked out" takes longer than it should.

Compliance reviews want repeatable evidence, not screenshots of one-off filters, and an on-call response wants a single grid that pivots quickly. Treating the security schema as a real grid turns triage into a calm checklist: read the lockout, see the trigger, decide, release or extend, annotate, move on. The plugin keeps doing what it does well; the operator finally gets a view that matches how investigations actually work.