In preparation
Security and
data protection.
This page is in preparation. That is the first fact. ISO/IEC 27001 is a target. We are not certified. We will not put a certificate number here because we do not have one.
Patrick Enwerem Limited still owes you a straight list of what is in place, what is not, and how to ask for more. That is this page. When the full control write-up is finished, this page will grow. It will not grow into a fake audit.
How to read a page that is not finished
Some vendors hide the unfinished part at the bottom. We put it at the top. If your score sheet requires a finished ISO 27001 certificate, we fail that row today. You can still read what we actually run. You can still ask for the watermarked pack. You can still walk away.
Do not treat this page as a completed ISMS manual. Treat it as a posture and a roadmap.
What is in place today
Public sites sit behind Cloudflare. Transport uses TLS. The application database encrypts data at rest at the provider. Access to client data is by role. Client rows are separated by row-level security. Secrets are meant to live in host secret stores, not in the git history we can avoid, and not in a chat. Card payments go through Paystack. Mail, bookings, and books go through Zoho. Object storage holds files such as voice output when that work is in scope. Unipile is used to connect the director's LinkedIn for outbound. A deleted, stopped, error, or credentials state is a stop.
These sentences are operational. They are not poetry. If one becomes false, we change the sentence.
What is not in place today
We do not have an ISO/IEC 27001 certificate. We do not publish a full statement of applicability on this site. We do not publish a public incident timeline. We do not publish a public vendor-risk register. We do not claim penetration-test dates we have not booked. We do not claim unhackable.
If you need any of those for a bid, ask. We will say what exists. We will not invent a date.
What this page will cover when the write-up is done
Encryption in more detail, including who holds which keys. Incident response: who is called, how fast we tell you, how we write the note. Business continuity and disaster recovery: what we restore first, and what we accept as delayed. Vendor risk: how we add a processor, how we drop one. Data residency: what we can pin, what we cannot pin, and how we say that in a SOW. Logging and monitoring: what we keep, for how long, and who can see it. Backups: how often, where, who can restore. Staff access: joiners, movers, leavers. Physical office: what a small Ibadan office can honestly claim, and nothing more.
Until those sections are written, Privacy and the compliance page are the live rules for data and company setup.
Shared responsibility
We run the platform pieces we named. You run your people, your lists, and your approvals.
If you upload a list you had no right to use, that is your breach of someone else's rights. We will still pause if we see it. We will not take the blame for a list we told you not to connect.
If you share an admin login, that is your hole. We will still reset access when you ask.
If a cloud provider has an outage, we will tell you when it touches you. We cannot make their status page untrue by writing a stronger adjective here.
Identity and access
People get the least access that still lets them do the job. Admin is not a souvenir. Service roles are not for browsers. The public anon key may appear in a browser. The service role must not.
A $250 audit buyer can see a result. They must not see outbound controls. A subscribed client can see ICP after they have paid for setup or retainer. Admin sees Outbound Config. Those walls are product design and security at the same time.
If an access wall is wrong, that is a defect. Tell us. Do not celebrate a bypass.
Passwords are not stored by us as homemade hashes. We use the auth provider. Turnstile sits on registration. Google sign-in keeps its own check. We do not log passwords. We do not ask for passwords in email.
Secrets
API keys, webhook secrets, and service roles belong in secret stores. They do not belong in a Replit chat, a WhatsApp screenshot, or a markdown file in git.
If a secret leaked, we rotate it. We do not argue about whether anyone saw it. We assume they did.
This page will not list secret names and values. Obviously.
Payments
Paystack takes the card. We do not want the full card number. The $250 audit slug is pelportal-audit. That payment must not switch outbound on. A setup or retainer payment may. If those two paths ever share a wire by mistake, that is a security and a commercial defect. It should be fixed, not marketed.
Mail and booking
Zoho Mail and Zoho Bookings are the tools. We do not run a shadow inbox on a free consumer account for official work. Invoice mail should come from info@penwerem.com once that path is authenticated. DKIM for Books waits on Zoho showing host and value. We do not invent DNS records.
Outbound connections
LinkedIn access, when used, is the director's account in the locked model. A client does not hand us their password in a spreadsheet. If a connection dies, sending dies. That is fail-closed. It can feel harsh. It is better than a ghost campaign.
Webhooks that change account state should carry a secret. Until that secret is set, a real disconnect may 401 and not pause. That is also fail-closed, and it is listed as work still to finish. It is not a feature.
Application security habits
We do not build raw SQL from user text. We do not open a public select on leads. We do not print secrets on an error page. We do not ship a public workers.dev as the main front door if we can help it. The public door is app.penwerem.com and penwerem.com and saleslevergtm.com. We do not leave a debug dump in the browser.
When a page dies with "This page didn't load", that is a defect. We fix the route. We do not tell users to ignore it.
Logging
We log enough to see a failure. We do not log a password. We do not log a full card. We do not log a raw token in a public console. Sign-in logs are not forever.
If a log would make a journalist's week and a client's year worse, we ask whether we need that log.
Backups and restore
The database provider holds backups as part of the hosted service. This page does not invent a restore-time number we have not tested in writing. If you need a restore objective in a SOW, we will write one we can keep, or we will refuse the number.
A restore is not a time machine for a bad send. Pause is the first tool.
Incidents
If we believe your data was accessed in a way it should not have been, we will tell you. We will say what we know, what we do not know, and what we paused. We will not wait to write a perfect narrative.
If the law requires a notice to a commission, we follow the law.
If a researcher reports a hole, we listen. We do not offer a bounty we have not funded. We also do not threaten a researcher who wrote in good faith.
Vendors, again
A new vendor that will see personal data should be named on the processor list for that job. A vendor that only sees encrypted blobs we cannot read is still a vendor. We do not add a clever new tool on a Friday night because a demo was pretty.
If a vendor's own ethics page is theatre, we still owe you our page.
Data residency
We can discuss pinning. We cannot honestly say every subprocess sits in one Nigerian building. Cloud is cloud. If your mandate requires in-country only, say so before kickoff. We will design for that or we will decline.
A public-sector search portal described as illustrative work on /work is not a certificate that every live job is in-country. Illustrative means illustrative.
Encryption, without magic words
In transit: TLS. At rest: provider encryption for the database. Backups: follow the provider unless a SOW says we hold a separate key. Device: people who work for us should lock their machines. That is a habit, not a hardware certification.
We do not claim a custom cipher. We do not claim quantum anything.
Physical office
The registered office is in Bodija, Ibadan. It is an office, not a bunker. Visitors sign in if we ask them to. Paper with personal data is not left on a cafe table. Laptops leave with their owners. This is ordinary discipline. It is not a tier-four data centre claim.
How clients should lock their side
Do not forward your admin login. Do not put a lead list in a public ticket. Do not ask us to connect a source you cannot defend. Do not screenshot a secret and send it to a group chat. Do not demand that we turn outbound on from a $250 audit.
If you do those things, our page cannot save you.
How we will finish this write-up
Section by section. Dated pack on request. No sudden certificate on a Monday. No badge shop.
When a section is finished, it will land on this page in the same voice. Cream and gold titles. Centred text. No amateur dump of RC and a date under the heading. The company name belongs in the sentences, not in a stamp block that looks like a student cover sheet.
Relationship to the other pages
Compliance is the company. Review is the human stop. Privacy is the data notice. This page is the technical posture and the honest gap.
If these pages fight, write info@penwerem.com and quote both lines.
Procurement questions we expect
Q: Certificate number? A: None.
Q: Last pen test? A: Ask. This page will not invent a date.
Q: Where is data? A: Cloud database with encryption at rest. Ask if you need a region pin. Do not assume Ibadan-only.
Q: Who is on-call? A: info@penwerem.com is the public door. A SOW can name a tighter channel.
Q: Do you use production data in demos? A: No.
Q: Can we run our own scan? A: Ask first. Do not attack the site to see what happens.
Q: Are you unhackable? A: No.
A note on workers.dev and extra hostnames
If an extra workers.dev hostname still answers, treat the branded host as the front door. Extra hostnames are debt. They are on the open list. They are not a second product.
A note on voice files
When a voice walkthrough is in scope, the file lives in object storage, not in a random inbox thread as the only copy. Access follows the same role idea. A $250 buyer can hear their result. They cannot use that as a key to someone else's result.
A note on Telegram
Telegram alerts, when used, are for the director or named operators. They are not a per-client chat product. Do not put a live lead's private note in a public channel. Per-client chat IDs are parked. Do not invent them on a Friday.
Closing
This is the security page of Patrick Enwerem Limited. It is unfinished on purpose. The unfinished mark is the most honest control we can show you today.
What is up: TLS, encryption at rest, roles, row-level security, Paystack, Zoho, a fail-closed stop when a connection dies.
What is not up: ISO certificate, public register of vendors, public incident timeline.
Ask for the pack if you are in a bid. Write info@penwerem.com if a line is wrong. Do not ask us to stamp a certificate we do not have.
Back to the Trust hub when you are done.
Device habits
Disk encryption on laptops. Screen lock. Updates. No unknown USB. No shared admin. These are habits. They are not a SOC visit. We still do them.
Home networks
People work from more than one room. We do not claim every home router is hardened by us. We do claim that client secrets should not sit in a family shared folder.
Mobile
Mail on a phone should lock. A screenshot of a lead list should not go to a story. Telegram alerts should not include a secret.
Test data
Test leads should look like test leads. They should be wiped before go / no-go. They should not be a real person's private mail used as a demo. I2 is the wipe. It is not optional because a chart looks nicer with extra rows.
Environments
Production is production. A preview is a preview. Secrets for production do not belong in a screenshot of a preview. Wrangler text rows that wipe on deploy are an operations bug. Anon keys that must survive a deploy belong in a secret store.
Dependencies
We pin known holes when we can. We do not click a blind fix-all that rewrites the app. A badge on a dashboard is not the same as a review.
Disclosure
If you found a hole, write info@penwerem.com. Include enough to reproduce. Do not include a threat. Do not include a ransom.
Lawful intercept
If a lawful order arrives, we follow it. We do not build a back door for convenience.
Closing addendum
Unfinished is a status, not a style. The finished parts are listed. The missing parts are listed. That is the whole trick.
How a security questionnaire should be filled
Most questionnaires were written for a company with a certificate wall. Ours will look thin if you only count badges. They look thicker if you count answers that match the live system.
Question: do you have an information security policy. Answer: this page is the public start. The full write-up is in preparation. Privacy and the compliance page are live.
Question: do you have a named CISO. Answer: write info@penwerem.com. We do not invent a title on a business card to fill a cell.
Question: do you encrypt data in transit. Answer: yes. TLS on the public sites.
Question: do you encrypt data at rest. Answer: yes, at the database provider.
Question: do you use multi-factor authentication. Answer: ask for the current state of the auth provider. This page will not invent a factor we have not turned on for every role.
Question: do you run annual penetration tests. Answer: we will not invent a date. If a test has been run, the pack can say so. If it has not, the cell is no.
Question: do you have a disaster recovery plan. Answer: the hosted database has provider backups. A numbered restore objective belongs in a SOW after we can keep it. It does not belong as a public boast.
Question: do you train staff annually. Answer: people who operate a live system must know how to pause and how to keep a secret. We do not publish an attendance spreadsheet on this site.
Question: do you have cyber insurance. Answer: ask in the commercial process. This page does not invent a policy number.
Question: can we audit you. Answer: a public body or a contracted client can ask for a review of the controls that touch their job. A stranger on the internet cannot book a scan by surprise.
Fill the form with those answers. Do not let a consultant "improve" them into yes on every row.
Joiners, movers, leavers
A joiner gets an account for the job they were hired to do. They do not get a tour of every client. They do not get a service role. They do not get a production secret in a welcome card.
A mover who changes role loses the old access when the new access starts. We do not stack roles because it is faster.
A leaver loses access the day they leave the job. Mail forwarding, if any, is a written choice. A leaver does not keep a personal copy of a lead list as a souvenir.
Contractors follow the same three beats. A contractor who finished last month should not still open the sheet this month.
If we miss a leaver, that is an incident even if nothing was stolen. Tell us if you see a name that should be gone.
How a day of access should look
Morning: the operator opens the branded host, not a leftover workers.dev link. They sign in. They see their rows. They do not see another client's rows.
Midday: they pause a cadence if a reply looks wrong. They do not paste a secret into a group chat to "just test".
Evening: they sign out on a shared machine. They do not leave a sheet on a projector.
Night: a webhook that says the LinkedIn connection is dead should stop sending. If the webhook secret is not yet set and the event 401s, sending should still not start from a guess. Fail closed.
Cookies, sessions, and browsers
Essential cookies run the site. Analytics wait for the banner. Session cookies should not be forever. A shared cafe computer should not keep an admin session after the person walks away.
We do not ask a browser to store a service role. We do not ask localStorage to hold a password. If a debug build ever printed a token in the console, that build should not be the public build.
Turnstile sits on Register. It does not belong on Sign in as a second gate that breaks the page. Google sign-in keeps its own bot check. If a future change puts Turnstile on Sign in again, treat that as a defect against the agreed look.
Public APIs and what must stay closed
A public select on leads is a defect. A public insert that creates a lead without a check is a defect unless that path is the intended public form, rate limited, and reviewed. A public RPC that returns another client's row is a defect. A signed URL that never expires is a defect if the file is a voice result or a private report.
If you find one of those, write. Do not post it. Do not sell it.
Rate limits and abuse
A form can be flooded. A login can be guessed. We rely on the host and the auth provider for a first line. We do not publish the exact numbers here because a published number becomes a target. If your job needs a written limit, the SOW can hold it.
We will not pretend a small company has a global scrubbing centre. Cloudflare is in front. That is the honest sentence.
Account recovery
If you lose a password, use the auth provider reset. We will not send you a new password in clear text. We will not reset an account because a stranger called and sounded urgent. We will not reset an admin because a Telegram message said so without a second check.
If your company email is gone, recovery gets slower. That is better than handing the sheet to the wrong person.
How we treat production data
Production data is not a demo. Production data is not a training pot for a public model. Production data is not a slide. Production data is not a screenshot in a group.
If we need to show a screen, we use a test row or we blur. If we cannot blur in time, we do not show the screen.
How we treat backups of files
Voice files and reports live in object storage when that work is in scope. A second copy in a random inbox is not the backup plan. If a file must be deleted at the end of a SOW, we delete the object we control. We cannot unsay a forward you made.
How we treat logs in more detail
A useful log says who did what, when, and whether it failed. A harmful log says the password they typed, the token they held, or the full card. We aim at the first. If a vendor log includes the second, we treat that as a vendor problem and we cut access if we must.
Logs are not a public archive. They are not a newsletter. They last long enough to debug and to meet a legal keep. They do not last as a gossip file.
How we treat third-party scripts on public pages
A public page should not load a random new tracker every week. The Trust look is cream, gold, and centred text. It does not need a pile of extra tags. If a tag is not needed to run the page or to measure with consent, it should not be there.
If a tag vendor is also a processor, they belong on the list.
How we treat DNS and mail authentication
Public hosts are the branded names. Extra workers.dev names are debt. Mail should authenticate as info@penwerem.com when the records are in place. We do not invent SPF, DKIM, or DMARC values on this page. If a record is missing, we say missing. We do not paste a guessed host.
How we treat source control
Private code belongs in a private repository. A classic personal access token, if used, is repo only, lives in the host secret store, and is not pasted into a chat. We do not purge git to hide a secret. We rotate the secret. History may still hold the old value. That is why rotation matters.
We do not commit a .env with live keys. We do not commit a service role.
How we treat previews and staging
A preview may use its own keys. Those keys should not open production rows. A preview that points at production data is a defect. A preview that is indexed by a search engine is a defect if it holds private screens.
Tell us if you found a preview that looks like production and is open to the world.
How we treat mobile apps we do not ship
We do not currently sell a consumer mobile app on this site. If a page is opened on a phone, it is still the web app. The same access rules apply. A phone screenshot is still a screenshot. It still should not hold a secret.
How we treat printers and paper
If we print a report, we treat the paper as the file. It does not stay on a shared printer. It does not go in a bin whole. This is ordinary. It still needs saying because questionnaires ask.
How we treat visitors to the office
The office is in Bodija, Ibadan. A visitor does not get a desk with a live admin session. A visitor does not plug a stick into a machine. A visitor who needs a network for their own work uses a guest path if we have one, not the staff path.
We do not claim a mantrap. We do not claim a badge system we have not installed. We claim a small office with ordinary locks and ordinary manners.
How we treat power and connectivity
Ibadan power is not a hidden fact. Machines should save. A live send should not depend on a single laptop staying open. Cloud hosts keep the app up when the office is dark. That is one reason the stop lives in the cloud path, not in a person's knee.
How we treat time zones
Nigeria is West Africa Time. Clients may sit elsewhere. A pause must work in their night and in ours. A booking is Zoho, not a guess at a time zone in a chat.
How we treat encryption keys we do not hold
If the database provider holds the at-rest key, we say so. If a SOW needs a customer-held key, that is extra design and extra fee. We will not tick that box for free and then fail it later.
How we treat deletion
Deletion means the object we control is gone or is queued to go. Backups may hold a copy until they expire. We will not promise instant global erasure of every cache. We will promise we do not keep a private museum of your leads.
If the law says keep an invoice, we keep the invoice.
How we treat legal holds
If a case needs a hold, we pause deletion on the named set. We do not hold the whole company because one row is in dispute. We do not hide a hold from the people who must know.
How we treat media requests after an incident
Press goes to info@penwerem.com. We do not brief a journalist with a client's file. We do not lie. We do not fill silence with a slogan.
How we treat competitors who ask security questions
A competitor is not a client. They get this public page. They do not get the watermarked pack. They do not get a tour.
How we treat students who want a dump
No. Write a question. Do not ask for a database export as coursework.
A walk through a typical bid annex
Annex A: legal name, RC 9180331, address, email. Annex B: this page plus Privacy. Annex C: processor list on request. Annex D: the honest no on ISO certificate. Annex E: the human stop on the review page. Annex F: invoice rules from the compliance page.
If your annex list is longer, send it. We will answer the extra rows or we will mark them not applicable. We will not mark them yes to look complete.
A walk through a typical incident hour
Minute one: pause the live path that looks wrong. Minute five: write down what we know. Minute fifteen: tell the client if their data or their send is in the blast. The rest of the hour: stop guessing, keep the record, rotate if a secret is in play.
We do not spend the first hour on a logo for the incident report.
A walk through a typical restore
Confirm what is lost. Confirm the point in time we can reach. Restore to a place we can inspect. Check that another client's rows did not arrive. Only then put it back in front of users.
If we cannot keep a one-hour restore, we will not write one-hour restore in a SOW.
A walk through a typical vendor add
Name the vendor. Name what they will see. Name where they sit. Name the lawful basis for any transfer. Name who can kill the integration. Add them to the list for that job. Do not add them on a Friday night because a demo was pretty.
A walk through a typical vendor drop
Turn the integration off. Revoke the key. Ask them to delete what the contract says they must delete. Keep the record. Tell the client if the drop touches them.
Words we will not put on this page later either
Unhackable. Military grade. Bank grade, unless a bank client writes their own standard into a SOW. Zero risk. Guaranteed uptime with no number we can keep. Certified, unless a certificate exists.
Words we will put on this page later when they become true
A certificate number, if one exists. A test date, if one exists. A restore number, if we tested it. A named extra security seat, if one is filled.
Until those words are true, they stay off.
How this unfinished page still helps a ministry
A ministry can see we will not fake a certificate. A ministry can see TLS, roles, and row-level security. A ministry can see Paystack and Zoho. A ministry can see a fail-closed stop. A ministry can ask for a pack watermarked to them. A ministry can walk away if the unfinished mark is too large.
That is more useful than a badge shop.
How this unfinished page still helps a founder
You can start work without waiting for a certificate theatre. You can still demand a pause. You can still demand that your rows stay your rows. You can still leave.
Last pass
If you only remember four lines, remember these.
ISO/IEC 27001 is a target. We are not certified. A human can stop a live path. Write info@penwerem.com when a line is wrong.
The rest of the write-up will arrive as facts arrive. It will not arrive as a sticker.
One page you can hand to a CISO tonight
TLS on the public hosts. Encryption at rest at the database. Roles. Row-level security. Paystack for cards. Zoho for mail, bookings, and books. Cloudflare in front. Fail-closed when a LinkedIn connection dies. ISO/IEC 27001 is a target, not a certificate. No public vendor register yet. No public incident timeline yet. No invented pen-test date. Write info@penwerem.com. Ask for the pack if you are in a bid. Do not scan us by surprise.