Most Singapore SMEs run IT on trust and tribal knowledge. The IT administrator who set everything up five years ago knows which servers do what, who has access to what, and what the WiFi password is. The problem is not that this works badly when he is in the office — it is what happens when he is not.
He resigns. He is on medical leave. He is involved in the incident. Suddenly nobody knows how to reset admin passwords, where the backup credentials are stored, which vendor has the support contract, or who to call when the server room floods at 2am.
IT governance — the documented policies, procedures, and controls that define how your organisation manages its technology — is what prevents this. It is not a corporate bureaucracy exercise. It is the difference between a business that can function when key people are unavailable, and one that cannot.
Under Singapore's PDPA, governance obligations are explicit: organisations must implement "reasonable security arrangements" to protect personal data, appoint a Data Protection Officer, and establish policies governing how personal data is collected, used, and protected. The PDPC has repeatedly found in enforcement decisions that the absence of documented policies — not just the absence of technical controls — constitutes a breach of the Protection Obligation.
Why IT Governance Matters Before You Scale
IT governance problems compound as businesses grow. A 5-person startup can function with informal IT management. By 30 people, the gaps start to hurt. By 60 people, they become genuine operational and compliance risks.
The inflection points where IT governance failures become critical:
First IT hire or MSP engagement. When someone other than the founder is responsible for IT, there needs to be documented processes for them to follow. "Ask Sean" is not a process.
First remote or hybrid working policy. Remote access without defined policies around acceptable use, device management, and VPN requirements is a security exposure.
First staff member departure. When staff leave, do you have a defined process for immediately revoking all access? How many former Singapore employees still have active logins to your systems? If you do not have an offboarding procedure, the answer is "more than you think."
First external audit or client due diligence. Enterprise clients and regulated industry customers increasingly require IT governance documentation as part of vendor qualification. Not having it can cost you a contract.
First cybersecurity incident. The PDPC, MAS, or cyber insurers will ask about your policies immediately. "We don't have written policies" is the answer that creates maximum regulatory and financial exposure.
The 7 Policies Every Singapore SME Should Have in Writing
1. Acceptable Use Policy (AUP)
What it covers: What employees may and may not do with company IT systems — computers, mobile devices, email, Internet access, cloud applications, and company data.
Why it matters: The AUP establishes the behavioural baseline for your IT environment. Without it, you have no documented standard to enforce when a staff member uses company systems for personal activities, downloads pirated software, or shares company data inappropriately. The AUP also establishes that monitoring of company systems is permitted — important for both legal compliance and incident response.
Key elements to include:
- Acceptable and prohibited uses of company devices and Internet access
- Rules governing personal use on company devices (clear, realistic policy — a blanket ban is rarely enforceable)
- Requirements around handling confidential and personal data
- Rules on installing software on company devices
- Statement that company IT systems may be monitored (required before implementing monitoring tools)
- Rules governing social media use on company time or devices
- Consequences of policy violation
2. Access Control Policy
What it covers: How access to IT systems and data is granted, reviewed, and revoked.
Why it matters: The PDPC has found in multiple enforcement decisions that excessive access — giving staff access to data they do not need — constitutes a failure of the Protection Obligation. Access control is also the primary defence against insider threats and the mechanism that limits damage when an account is compromised.
Key elements to include:
- Role-based access — access granted based on job function, not individual requests
- Principle of least privilege — minimum access required to perform the job role
- Process for requesting new access (who can approve, documentation required)
- Administrator and privileged account management — separate admin accounts, not using admin credentials for day-to-day work, MFA mandatory
- Access review schedule — how often access is reviewed and by whom (recommended: quarterly for privileged accounts, annually for all staff)
- Offboarding procedure — access revocation timeline upon staff departure (all access revoked on last working day or upon notification of departure)
- Guest and contractor access — temporary, time-limited, with defined scope
3. Password Policy
What it covers: Requirements for creating and managing passwords for all company systems.
Why it matters: Weak or reused passwords remain one of the most common attack vectors in Singapore cybersecurity incidents. The MAS Notice on Cyber Hygiene requires financial institutions to implement MFA on administrative accounts and enforce strong password requirements. For non-financial SMEs, these requirements represent best practice even if not legally mandated.
Key elements to include:
- Minimum password length (14 characters minimum recommended; NIST guidance has moved away from complexity rules toward length)
- MFA requirement — which systems require MFA (recommended: all external-facing systems, all admin accounts, email, VPN, Microsoft 365/Google Workspace)
- Password manager usage — company-managed password manager (1Password, Bitwarden, Keeper) for storing and generating passwords
- Password sharing prohibition — no sharing of credentials between staff members
- Default password change requirement — all default vendor credentials changed immediately on deployment
- Password reuse prohibition
- Incident response — what to do if a password is believed compromised
4. Data Classification and Handling Policy
What it covers: How company data is categorised by sensitivity and what handling requirements apply to each category.
Why it matters: Not all data requires the same level of protection. A data classification policy ensures that personal data (protected under PDPA), confidential commercial information, and financial data are handled appropriately, while less sensitive data is not over-protected at unnecessary cost.
Recommended classification tiers for Singapore SMEs:
| Classification | Definition | Handling Requirements |
|---|---|---|
| Public | Marketing materials, public website content | No restrictions |
| Internal | General company communications, procedures | Share freely internally; do not share externally without approval |
| Confidential | Client data, commercial contracts, financial records | Restricted to authorised staff; encrypt in transit and at rest; secure deletion required |
| Personal Data (PDPA) | Any data that identifies an individual | Governed by PDPA obligations; additional controls for collection, use, transfer, and retention |
| Restricted | Passwords, encryption keys, audit logs, HR records | Strictly limited to need-to-know; additional access controls |
Key elements to include:
- Classification definitions and examples
- Labelling requirements (how documents should be marked)
- Storage requirements by classification (where each tier may be stored)
- Sharing and transfer rules by classification
- Retention and disposal requirements — including PDPA retention limits
5. BYOD Policy (Bring Your Own Device)
What it covers: Whether and how personal devices may be used to access company systems and data.
Why it matters: In Singapore's hybrid working environment, BYOD is effectively the default for many SMEs — staff use personal phones for WhatsApp business communications, personal laptops to access company email from home, and personal tablets for video calls. Without a policy, this access is unmanaged, unmonitored, and unprotected.
Key elements to include:
- Permitted device types and operating systems (iOS, Android, Windows, macOS — define which are supported)
- Required security controls on personal devices accessing company data: device PIN/passcode, screen lock timeout, device encryption, company MDM enrollment (if applicable)
- Right to remote wipe: if a personal device is used for company data and is lost or the employee departs, does the company have the right to wipe company data? This must be agreed in advance.
- Data segregation: personal and company data should be kept separate (MDM tools like Microsoft Intune or Jamf enforce this through work profiles)
- Acceptable use on personal devices: same restrictions as company device AUP for company-related activities
- Exit procedure: company data must be removed from personal devices upon departure
6. Incident Response Policy
What it covers: What to do when a security or IT incident occurs.
Why it matters: When a ransomware attack, data breach, or major system failure occurs is not the time to figure out what to do. An incident response policy defines roles, escalation procedures, communication protocols, and notification requirements in advance — when there is time to think clearly.
PDPA notification obligation: Organisations must notify the PDPC of a data breach that results in or is likely to result in significant harm to individuals, within 3 calendar days of determining it is a notifiable breach. This is a hard deadline. Without a documented incident response process, organisations frequently fail to meet it.
Key elements to include:
- Incident classification (what constitutes a cybersecurity incident vs a regular IT issue)
- Roles and responsibilities during an incident (who leads, who communicates, who engages external support)
- Initial response checklist: isolate, preserve evidence, assess scope
- Internal communication protocol (who needs to be informed, in what order)
- External notification requirements: PDPC (if personal data breach), MAS (if financial institution), customers, and partners
- Engagement of external resources: MSP, cyber incident response firm, cyber insurance provider
- Documentation requirements: log of actions taken and timeline
- Post-incident review: root cause analysis and remediation within 30 days
7. Vendor and Third-Party Access Policy
What it covers: How external parties (vendors, contractors, IT providers) access your systems and data.
Why it matters: Many Singapore cybersecurity incidents involve compromised vendor credentials or third-party access that was not properly managed. The PDPC has found third-party management failures in multiple enforcement decisions. Under PDPA, organisations are responsible for ensuring their vendors protect personal data appropriately.
Key elements to include:
- Vendor onboarding checklist: security assessment requirements before granting access
- Access provisioning: how vendor accounts are created, what access is granted (minimum necessary), and who approves
- Access monitoring: vendor activity on your systems should be logged
- Contractual requirements: data protection agreement (DPA) required from any vendor that processes personal data on your behalf
- Access revocation: vendor access revoked immediately when engagement ends
- VPN or dedicated access channel for vendor remote access — not sharing staff credentials
Building Your IT Governance Documentation: Practical Steps
The most common reason Singapore SMEs do not have written IT policies is not disagreement with the principle — it is inertia. Here is a practical approach:
Step 1 — Prioritise. Do not try to write all 7 policies simultaneously. Start with the two that carry the most regulatory risk: Access Control Policy (PDPA) and Incident Response Policy (PDPA notification deadline). These are the most likely to be demanded by a regulator or auditor.
Step 2 — Draft, do not perfect. A documented policy that is 80% right and exists is vastly better than a perfect policy that never gets written. Draft each policy in plain English — you do not need legal language.
Step 3 — Get acknowledgment in writing. Every staff member should sign or digitally acknowledge the AUP and Password Policy as part of onboarding. This establishes that they have read and understood the requirements.
Step 4 — Schedule reviews. Policies become outdated. Build an annual review cycle — typically anchored to an audit or the start of the financial year — that ensures policies reflect current systems, current risks, and current regulatory requirements.
Step 5 — Test the incident response policy. Run a tabletop exercise at least annually. Walk through a simulated ransomware scenario with your management team. Identify gaps in the response plan before you need it for real.
What We Typically See When Reviewing Client IT Governance
Access is never revoked. Former employees, former contractors, and former vendors continue to have active accounts weeks or months after their engagement ended. In some cases, accounts are never disabled — just unused. This is both a security risk and a PDPA obligation failure.
The IT administrator holds all credentials personally. No documented credential inventory exists. When the administrator is unavailable, nobody knows how to access systems, contact vendors, or reset passwords.
The AUP was written once, never updated, never signed. The policy references systems that were decommissioned years ago and does not cover cloud applications that are now central to operations.
No PDPA-aligned data handling policy. The business collects personal data, stores it in various places, and has no documented retention periods or disposal procedures. Under PDPA, this is a compliance gap — and the PDPC does ask about it.
Vendor contracts without DPAs. Cloud services, CRM platforms, payroll systems — all processing personal data — without a signed data processing agreement. The PDPA requires this for any vendor that processes personal data on your behalf.
Frequently Asked Questions
What does IT governance actually mean for an SME, versus enterprise frameworks like COBIT or ITIL?
For an SME, IT governance means having a small set of documented policies, procedures, and controls that define how technology is managed — not adopting a full enterprise framework like COBIT or ITIL. In practice this means the 7 core policies covered above (acceptable use, access control, password, data classification, BYOD, incident response, and vendor access) written in plain English and actually followed, rather than a heavyweight compliance programme. The goal is lightweight governance that reduces risk without slowing the business down, not paperwork for its own sake.
What's the minimum IT governance an SME needs to be PDPA-compliant?
At minimum, you need documented policies for access control and incident response, since these carry the most regulatory risk — the PDPC has found in enforcement decisions that the absence of documented policies, not just missing technical controls, constitutes a breach of the Protection Obligation. You also need a data classification and handling policy that reflects PDPA retention and disposal requirements, and vendor agreements (DPAs) with any third party that processes personal data on your behalf. The PDPA also requires appointing a Data Protection Officer and implementing "reasonable security arrangements," so governance and compliance are directly linked rather than separate exercises.
Who should own IT governance in a company without a dedicated CIO?
Ownership should sit with whoever is accountable for IT decisions day-to-day — often the founder, an operations lead, or the first IT hire/MSP — but the critical requirement is that the responsibility is documented and does not depend on one person's tribal knowledge. The scenario this guide opens with (the IT administrator who resigns, goes on leave, or is unavailable during an incident) is exactly what governance is meant to prevent: policies, credential inventories, and procedures need to exist independently of any single individual. Practically, this often means the business owner or ops lead sponsors the policies while an MSP or IT provider helps draft and maintain them.
How does IT governance differ from IT security?
IT governance is the documented framework of policies, procedures, and controls that defines how technology decisions get made and enforced — things like who approves access requests, how incidents get escalated, and how vendors are onboarded. IT security is the set of technical controls (firewalls, endpoint protection, MFA) that governance policies require and reference. You can have security tools in place without governance (technical controls with no documented policy behind them), and you can have governance without adequate security (policies that exist on paper but aren't backed by the right controls) — the two need to work together, which is why policies like the Password Policy and Access Control Policy explicitly define required technical measures like MFA.
What are the practical first steps to establish IT governance from scratch?
Start by prioritising the two policies with the most regulatory risk — Access Control and Incident Response — rather than trying to write all 7 simultaneously. Draft each policy in plain English aiming for 80% right rather than perfect, get staff to sign or digitally acknowledge the AUP and Password Policy during onboarding, and schedule an annual review cycle so policies stay current as systems change. Finally, run a tabletop exercise at least once a year to test the incident response policy against a simulated scenario before you actually need it.
Book a Free IT Governance Review with Aggasys
Aggasys helps Singapore SMEs establish the IT governance foundations they need — from policy templates to access control audits to PDPA-aligned data handling procedures. Our free IT governance review identifies your current gaps and provides a prioritised roadmap to address them.
Book your free governance review: aggasys.com/contact or call (+65) 6250 0045.