SSIK IT Consulting & Solutions

Why SSIK started

SSIK IT Consulting & Solutions began as a shared effort between Ghayas Sher and me to turn classroom knowledge into a controlled consulting workflow. We share SSIK's co-founder, consulting, security-assessment, privacy-research, and stakeholder-communication responsibilities. In addition to that shared work, I independently built the public website and the private SSIK Intelligence V1 platform that supports the internal process.

The project is intentionally passive by design. It organizes public business information and non-intrusive observations; it does not send outreach automatically, exploit systems, bypass access controls, or perform invasive testing. Any future engagement would require explicit authorization and a clearly defined scope.

Public information structure

The nine-page public website had to explain what the organization does without implying work that has not occurred. Service descriptions separate readiness reviews, infrastructure guidance, privacy research, and possible future authorized assessments. Contact and ownership information are presented consistently, while internal research and customer material stay outside the public repository.

SSIK Intelligence workflow

The local-first internal platform uses a twelve-stage workflow so research does not become an unreviewed pile of targets. Work moves through discovery, normalization, evidence collection, deduplication, review, prioritization, approval, export, rescanning, recovery, and audit states. Durable jobs allow the platform to resume after interruption instead of silently abandoning a run.

• Workspaces separate unrelated research and permissions.
• Role-based access control limits administrative and review actions.
• URL and network validation reduce server-side request forgery risk.
• Runtime and queue limits keep unattended work bounded.
• Evidence and audit records explain why an item changed state.
• Previously reviewed targets can be deprioritized while new coverage areas refill the queue.

Verification

The private platform currently passes 110 automated tests together with lint, type, migration, integrity, and secret checks. Outbound delivery remains disabled and mock-only, so validation cannot accidentally contact a researched organization. Those checks cover the application logic and known defensive boundaries; they do not equal an independent security assessment or prove that every future deployment configuration is safe.

The public website is maintained through GitHub Pages. Deployment status, source ownership, and public claims are checked separately so the site does not describe internal capabilities that the platform has not demonstrated.

Risk boundaries

The platform stores business research and operational history, so authentication, authorization, auditability, and export control matter even when the underlying sources are public. Public information can still become sensitive when it is aggregated, scored, or associated with internal decisions.

The current project does not claim automated penetration testing, guaranteed vulnerability discovery, customer authorization, production-scale scanning, or regulatory certification. These boundaries remain visible because they determine what the evidence can actually support.

Lessons and next milestones

The largest lesson is that workflow design is a security control. A technically correct scanner can still create risk if it lacks ownership, review gates, bounded execution, evidence retention, or a clear stop condition.

Future milestones include refining the review experience, improving recovery reporting, validating deployment assumptions, documenting an authorized engagement lifecycle, and separating reusable public components from private operational logic.